深入解读 open-code-review 的 Kotlin 代码审查规则从空安全到协程与 Java 互操作【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-reviewopen-code-reviewOCR内置了覆盖 40 语言的多语言规则集其中 Kotlin 审查规则 面向*.kt/*.kts源码聚焦空安全、死代码、协程、集合性能、类设计、资源管理与 Java 互操作等 9 大主题。本文将逐条拆解该规则文档的检查要点与正反示例并结合本仓库源码说明这些规则如何被解析、匹配、注入到 LLM 审查提示词中以及如何用ocr rules check验证与定制你的 Kotlin 审查策略。一、Kotlin 规则在 open-code-review 中的落地方式在深入规则内容之前先理解这份文档在系统中的位置kotlin.md是 open-code-review 内置系统规则层system rule layer的一份规则体rule body它通过三层机制生效。1. 路径匹配**/*.{kt,kts}→kotlin.md内置规则映射表 system_rules.json 中有一条关键记录**/*.{kt,kts}: kotlin.md即任何路径下**可跨目录深度匹配以.kt或.kts结尾的文件都会解析到kotlin.md这份规则。{kt,kts}花括号会被 system_rules.go 中的expandBraces展开为**/*.kt与**/*.kts两条独立模式再逐一匹配源码注释中的示例正是*.go.{java,kotlin} → [*.go.java, *.go.kotlin]。匹配采用bmatcuk/doublestar/v4库规则为大小写不敏感路径先转小写再匹配、首个匹配优先first match wins。2. 内嵌分发go:embed与LoadDefault规则文档通过//go:embed system_rules.json rule_docs/*system_rules.go编译进二进制LoadDefault()读取rule_docs/kotlin.md后将PathRules[i].Rule从文件名替换为完整规则文本system_rules.go。因此你不需要联网、也不需要额外下载内置规则始终可用。3. 文件过滤扩展名白名单与测试文件排除在规则解析之前文件要经过五道过滤门binary → user_exclude → user_include → unsupported_ext → default_path见 review-rules.md。与 Kotlin 直接相关的两道门是扩展名白名单supported_file_types.json.kt与.kts均被列为受支持类型这是.kt/.kts文件能进入审查流程的前提默认路径排除default_exclude_patterns.json**/src/test/**/*.{kt,kts}—— 位于src/test/下的 Kotlin 测试代码默认不参与审查避免 LLM 把精力浪费在测试文件上。若你确实需要审查这些文件可在用户层include中显式声明include可绕过 default_path 门。4. 四层优先级链与{{system_rule}}占位符kotlin.md处于优先级最低的内置系统层。composedResolversystem_rules.go按如下顺序尝试解析每个文件的规则优先级来源说明1最高--rule命令行参数单次运行覆盖始终优先2repoDir/.opencodereview/rule.json项目级规则可提交入库3~/.opencodereview/rule.json全局个人偏好4最低内嵌system_rules.json含kotlin.md兜底始终存在解析得到的规则文本最终会填入 plan / main 任务提示词中的{{system_rule}}占位符成为 LLM 对该文件实施审查时遵循的审查清单。也就是说这份kotlin.md就是模型在审查每个.kt/.kts文件时被明确要求的检查大纲。补充用户规则默认替换系统规则若项目规则设置了merge_system_rule: true则系统规则会以 System-Specific Rules (Mandatory) 前缀与用户规则拼接合并见 system_rules.goKotlin 内置检查仍会被强制执行。二、规则 1空安全Null Safety问题可空类型nullable type未正确处理导致潜在的NullPointerExceptionKotlin 中即NullPointerException/ KotlinNullPointerException。检查要点避免过度使用!!非空断言优先使用安全调用?.或 Elvis 运算符?:确保 data class 或 API 响应中的可空属性被妥善处理。反例val length: Int text!!.length // Risk: text may be null改进val length: Int text?.length ?: 0 // Safe handling!!的本质是把空值风险推迟到运行时由 JVM 抛出异常它等于在代码里埋了一颗隐性炸弹。?.链式安全调用遇到空值直接短路返回 null再配合?:提供默认值语义清晰且无崩溃风险。对从网络、数据库、反序列化等边界进入的数据data class 属性、API response 字段默认都应视为可空并显式处理。死代码Dead Code该小节附在空安全之后属于通用检查项包括三类永不可达的代码块如条件恒为 false 的分支、return语句之后的代码声明但从未读取/引用的变量大段被注释掉的代码且无保留意图的说明。死代码会误导维护者让人误以为分支仍可能执行也白白消耗 LLM 的上下文窗口。审查时若发现此类代码应建议删除或补充保留理由。三、规则 2函数与表达式简洁性问题冗余代码削弱了 Kotlin 的简洁性conciseness。检查要点用简化单表达式函数如fun sum(a: Int, b: Int) a b用when替代复杂的if-else链避免不必要的return如 lambda 中直接使用表达式结果。反例fun getGrade(score: Int): String { if (score 90) return A else if (score 80) return B else return C }改进fun getGrade(score: Int) when { score 90 - A score 80 - B else - C }when是 Kotlin 对多重分支的标准答案表达式化、无穿透、天然返回结果。单表达式函数配合省略函数体花括号与return让意图更直白、diff 更小。这一项审查的是代码是否符合 Kotlin 的惯用表达而非仅检查功能正确性。四、规则 3集合操作优化问题低效的集合操作引发性能问题尤其是中间集合对象的产生。检查要点大集合优先使用Sequence惰性求值减少中间对象避免冗余操作如把多个filter合并成一个使用groupBy、associate等内置函数替代手写循环。反例val evenSquares listOf(1, 2, 3).map { it * it }.filter { it % 2 0 } // creates intermediate collections改进val evenSquares listOf(1, 2, 3).asSequence() .map { it * it } .filter { it % 2 0 } .toList() // lazy evaluation对List的每个操作符都会立即执行并产出一个新集合上面的map生成一个中间 listfilter再生成一个。当集合规模很大或操作链很长时内存与 GC 压力可观。asSequence()将操作链改为惰性流水线元素逐个流过map → filter最终一次性toList()收集结果。判断依据集合越大、操作符越多转 Sequence 的收益越明显小集合上 Sequence 的装箱与创建开销可能反而略高需按场景取舍。此外groupBy/associate/partition等标准函数通常比手写循环更不易出错、也更容易被 JIT 优化。五、规则 4协程的正确使用问题协程泄漏coroutine leak或异常处理不当。检查要点使用结构化并发coroutineScope或supervisorScope管理生命周期避免GlobalScope容易资源泄漏异常处理将withContext或async包裹在try/catch中。反例GlobalScope.launch { // escapes scope, may leak fetchData() }改进viewModelScope.launch { // structured concurrency try { withContext(Dispatchers.IO) { fetchData() } } catch (e: Exception) { /* handle exception */ } }GlobalScope的协程生命周期与任何调用方无关——发起方销毁后协程仍在后台飘着既浪费资源又难以取消这是典型的泄漏源。结构化并发structured concurrency的原则是协程必须在其父作用域内、随父作用域同生共死viewModelScope或lifecycleScope、coroutineScope、supervisorScope保证页面销毁即整体取消withContext(Dispatchers.IO)负责线程切换而异常用try/catch就地收敛避免未处理异常冒泡到全局崩溃。六、规则 5类与对象设计问题没有利用 Kotlin 的语言特性导致冗余实现。检查要点Data class纯数据对象使用data class自动生成equals/hashCode/toString/copy/componentNSealed class/interface受限类型层级用sealed class配合when穷尽性检查编译期保证分支完备委托Delegation属性委托如by lazy或类委托by实现装饰器模式。反例class User(val name: String) { // manually implementing toString()/equals()... }改进data class User(val name: String) // standard methods auto-generated手写equals/hashCode/toString极易出 bug比如hashCode忘了纳入某个参与equals的字段导致 map 查找失效。data class由编译器按主构造函数属性统一生成这些方法行为一致且省心。同样地sealed class让when分支的穷尽性由编译器保障——未来新增子类型时未处理它的when会直接编译失败把漏分支从运行时错误变成编译期错误。七、规则 6资源管理与作用域函数问题资源未释放或作用域函数scope functions误用。检查要点使用use自动关闭文件/网络资源如FileInputStream().use { ... }作用域函数let、apply等应保持可读性避免过度嵌套。反例val file File(path) val reader BufferedReader(FileReader(file)) // forgot to call reader.close()改进File(path).inputStream().use { stream - // resource auto-closed }Java 时代finally { reader.close() }的样板代码在 Kotlin 中被use取代它接收一个Closeable保证代码块无论正常返回还是抛异常都会关闭资源。审查时重点看所有打开的文件流、Socket、数据库连接是否都通过use或useLines、useBufferedReader等变体管理。作用域函数方面let/run/with/apply/also各有其惯用场景——如apply适合对象初始化配置、let适合空值检查后操作滥用会导致it/this混乱嵌套过深时应抽成具名函数。八、规则 7性能陷阱问题隐藏的性能开销hidden performance overhead。检查要点内联函数高阶函数使用inline降低 lambda 开销但避免内联大型函数常量编译期常量用const val而非val避免在循环内创建对象如Regex实例。三点逐一展开inline将函数体在调用点展开消除 lambda 对应的匿名类对象分配。对高频调用的高阶函数如集合操作的回调收益明显但内联会放大字节码体积大函数内联会拖慢编译并增加方法体大小限制风险所以只适合小函数const val是真正的编译期常量会被内联进引用处、且可用于注解参数annotation arguments而普通val只是运行时只读属性。能用const val的地方编译期已知的字面量就不要用val循环内Regex(...)每次迭代都重新编译模式应提取为顶层private val pattern Regex(...)复用。九、规则 8Java 互操作Interoperability问题Java 代码调用 Kotlin 代码时出现兼容性问题。检查要点使用JvmStatic与JvmOverloads优化暴露给 Java 调用方的 API空安全注解使用Nullable/NonNull帮助 Java 侧识别可空性。原因在于Kotlin 的可空性、默认参数、伴生对象companion object等特性在 JVM 层面并没有一等公民的表达。若你的 Kotlin 代码会被 Java 调用需要主动铺桥默认参数在 Java 眼里不存在JvmOverloads会让编译器为每个默认参数组合生成重载方法伴生对象中的成员默认属于静态内部类实例JvmStatic才能生成真正的静态方法让 Java 用User.create()而非User.Companion.create()调用Kotlin 的可空类型对 Java 是无标注platform type的Nullable/NonNull或 JSR-305 注解能帮助 IDE 与静态分析工具在 Java 侧正确提示空值风险。十、规则 9其他关键点不可变性Immutability优先val而非var。不可变引用让数据流更可预测、天然线程安全、便于推理。只有当变量确实需要重新赋值时才用var字符串处理使用字符串模板Value: $value含${expr}表达式插值而非字符串拼接Value: value。模板更简洁、可读性更高编译器处理也更具确定性。这两点虽未给出正反例但在审查实践中出现频率极高——尤其var滥用是并发 Bug 的温床属于 Kotlin 审查的高性价比检查项。十一、验证与调试ocr rules check规则解析过程并不透明实际生效的规则可能与直觉不符例如项目里某个**/*.kt自定义规则拦截了系统规则。open-code-review 提供ocr rules check命令直接查看给定文件路径解析出的规则、来源层与匹配模式实现见 rules_cmd.go。# 查看 src/main/kotlin/com/example/UserService.kt 解析到的规则 ocr rules check src/main/kotlin/com/example/UserService.kt输出示例File: src/main/kotlin/com/example/UserService.kt Source: System built-in Pattern: **/*.{kt,kts} Rule: ──────────────────────────────────────── …kotlin.md 的完整内容… ────────────────────────────────────────若携带自定义规则文件ocr rules check --rule custom.json src/main/kotlin/com/example/UserService.kt此时Source会显示Custom (--rule)、Pattern显示你自定义的匹配模式。该命令背后调用rules.NewResolverResolveDetail与真实审查流程共享同一套解析逻辑因此检查结果即审查时的实际生效规则。仓库测试也印证了.kt/.kts的解析行为system_rules_test.go 中{app.kt, Null Safety}、{scripts/setup.kts, Null Safety}断言app.kt与setup.kts均解析到包含 Null Safety 的 kotlin.md 规则体另有{src/main/bar.kt, jvm-rule}验证项目级自定义规则可覆盖系统规则lib/**/*.kt的 include /**/tmp/**的 exclude 过滤也都有对应用例。十二、定制你的 Kotlin 审查策略内置kotlin.md是通用基线真实项目往往需要叠加团队规范。推荐做法是把自定义规则写入repoDir/.opencodereview/rule.json并提交入库{ rules: [ { path: **/*.{kt,kts}, rule: 团队附加要求所有 public API 必须显式标注 JvmOverloads若被 Java 调用禁止在循环体内创建 Regex 实例data class 属性一律使用 val。, merge_system_rule: true } ] }设置merge_system_rule: true后模型得到的提示词为System-Specific Rules即本文章讲解的 kotlin.md 全文 User-Specific Rules团队要求两部分内置空安全、协程等检查仍然强制保留。若不设置该字段则团队规则完全替换系统规则。其他层级同理~/.opencodereview/rule.json放个人全局偏好单次 PR 需要不同检查清单时用ocr review --rule ./security-only.json覆盖所有层级。规则文件中的rule字段既可以是内联文本也可以引用.md/.txt文件路径扩展名白名单 512KB 大小上限 路径穿越校验见 system_rules.go。结语kotlin.md是 open-code-review 内置 Kotlin 审查清单的完整形态从!!滥用、死代码、if-else链、集合中间对象、GlobalScope泄漏到 data class/sealed class、use资源管理、inline/const val性能、JvmOverloads互操作九个方向覆盖了 Kotlin 项目最常见的质量风险。它经由 system_rules.json 的**/*.{kt,kts}模式、go:embed内嵌分发与四层优先级链最终注入 LLM 提示词而ocr rules check让你能随时确认这份规则对某个文件是否真的生效。理解这份规则文档的每一处细节你就能更准确地预测 open-code-review 的审查行为并在此基础上叠加属于自己团队的 Kotlin 规范。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/13 12:07:37 · 阅读 1.2k 深入解读 open-code-review 的 Kotlin 代码审查规则：从空安全到协程与 Java 互操作
深入解读 open-code-review 的 Kotlin 代码审查规则从空安全到协程与 Java 互操作【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-reviewopen-code-reviewOCR内置了覆盖 40 语言的多语言规则集其中 Kotlin 审查规则 面向*.kt/*.kts源码聚焦空安全、死代码、协程、集合性能、类设计、资源管理与 Java 互操作等 9 大主题。本文将逐条拆解该规则文档的检查要点与正反示例并结合本仓库源码说明这些规则如何被解析、匹配、注入到 LLM 审查提示词中以及如何用ocr rules check验证与定制你的 Kotlin 审查策略。一、Kotlin 规则在 open-code-review 中的落地方式在深入规则内容之前先理解这份文档在系统中的位置kotlin.md是 open-code-review 内置系统规则层system rule layer的一份规则体rule body它通过三层机制生效。1. 路径匹配**/*.{kt,kts}→kotlin.md内置规则映射表 system_rules.json 中有一条关键记录**/*.{kt,kts}: kotlin.md即任何路径下**可跨目录深度匹配以.kt或.kts结尾的文件都会解析到kotlin.md这份规则。{kt,kts}花括号会被 system_rules.go 中的expandBraces展开为**/*.kt与**/*.kts两条独立模式再逐一匹配源码注释中的示例正是*.go.{java,kotlin} → [*.go.java, *.go.kotlin]。匹配采用bmatcuk/doublestar/v4库规则为大小写不敏感路径先转小写再匹配、首个匹配优先first match wins。2. 内嵌分发go:embed与LoadDefault规则文档通过//go:embed system_rules.json rule_docs/*system_rules.go编译进二进制LoadDefault()读取rule_docs/kotlin.md后将PathRules[i].Rule从文件名替换为完整规则文本system_rules.go。因此你不需要联网、也不需要额外下载内置规则始终可用。3. 文件过滤扩展名白名单与测试文件排除在规则解析之前文件要经过五道过滤门binary → user_exclude → user_include → unsupported_ext → default_path见 review-rules.md。与 Kotlin 直接相关的两道门是扩展名白名单supported_file_types.json.kt与.kts均被列为受支持类型这是.kt/.kts文件能进入审查流程的前提默认路径排除default_exclude_patterns.json**/src/test/**/*.{kt,kts}—— 位于src/test/下的 Kotlin 测试代码默认不参与审查避免 LLM 把精力浪费在测试文件上。若你确实需要审查这些文件可在用户层include中显式声明include可绕过 default_path 门。4. 四层优先级链与{{system_rule}}占位符kotlin.md处于优先级最低的内置系统层。composedResolversystem_rules.go按如下顺序尝试解析每个文件的规则优先级来源说明1最高--rule命令行参数单次运行覆盖始终优先2repoDir/.opencodereview/rule.json项目级规则可提交入库3~/.opencodereview/rule.json全局个人偏好4最低内嵌system_rules.json含kotlin.md兜底始终存在解析得到的规则文本最终会填入 plan / main 任务提示词中的{{system_rule}}占位符成为 LLM 对该文件实施审查时遵循的审查清单。也就是说这份kotlin.md就是模型在审查每个.kt/.kts文件时被明确要求的检查大纲。补充用户规则默认替换系统规则若项目规则设置了merge_system_rule: true则系统规则会以 System-Specific Rules (Mandatory) 前缀与用户规则拼接合并见 system_rules.goKotlin 内置检查仍会被强制执行。二、规则 1空安全Null Safety问题可空类型nullable type未正确处理导致潜在的NullPointerExceptionKotlin 中即NullPointerException/ KotlinNullPointerException。检查要点避免过度使用!!非空断言优先使用安全调用?.或 Elvis 运算符?:确保 data class 或 API 响应中的可空属性被妥善处理。反例val length: Int text!!.length // Risk: text may be null改进val length: Int text?.length ?: 0 // Safe handling!!的本质是把空值风险推迟到运行时由 JVM 抛出异常它等于在代码里埋了一颗隐性炸弹。?.链式安全调用遇到空值直接短路返回 null再配合?:提供默认值语义清晰且无崩溃风险。对从网络、数据库、反序列化等边界进入的数据data class 属性、API response 字段默认都应视为可空并显式处理。死代码Dead Code该小节附在空安全之后属于通用检查项包括三类永不可达的代码块如条件恒为 false 的分支、return语句之后的代码声明但从未读取/引用的变量大段被注释掉的代码且无保留意图的说明。死代码会误导维护者让人误以为分支仍可能执行也白白消耗 LLM 的上下文窗口。审查时若发现此类代码应建议删除或补充保留理由。三、规则 2函数与表达式简洁性问题冗余代码削弱了 Kotlin 的简洁性conciseness。检查要点用简化单表达式函数如fun sum(a: Int, b: Int) a b用when替代复杂的if-else链避免不必要的return如 lambda 中直接使用表达式结果。反例fun getGrade(score: Int): String { if (score 90) return A else if (score 80) return B else return C }改进fun getGrade(score: Int) when { score 90 - A score 80 - B else - C }when是 Kotlin 对多重分支的标准答案表达式化、无穿透、天然返回结果。单表达式函数配合省略函数体花括号与return让意图更直白、diff 更小。这一项审查的是代码是否符合 Kotlin 的惯用表达而非仅检查功能正确性。四、规则 3集合操作优化问题低效的集合操作引发性能问题尤其是中间集合对象的产生。检查要点大集合优先使用Sequence惰性求值减少中间对象避免冗余操作如把多个filter合并成一个使用groupBy、associate等内置函数替代手写循环。反例val evenSquares listOf(1, 2, 3).map { it * it }.filter { it % 2 0 } // creates intermediate collections改进val evenSquares listOf(1, 2, 3).asSequence() .map { it * it } .filter { it % 2 0 } .toList() // lazy evaluation对List的每个操作符都会立即执行并产出一个新集合上面的map生成一个中间 listfilter再生成一个。当集合规模很大或操作链很长时内存与 GC 压力可观。asSequence()将操作链改为惰性流水线元素逐个流过map → filter最终一次性toList()收集结果。判断依据集合越大、操作符越多转 Sequence 的收益越明显小集合上 Sequence 的装箱与创建开销可能反而略高需按场景取舍。此外groupBy/associate/partition等标准函数通常比手写循环更不易出错、也更容易被 JIT 优化。五、规则 4协程的正确使用问题协程泄漏coroutine leak或异常处理不当。检查要点使用结构化并发coroutineScope或supervisorScope管理生命周期避免GlobalScope容易资源泄漏异常处理将withContext或async包裹在try/catch中。反例GlobalScope.launch { // escapes scope, may leak fetchData() }改进viewModelScope.launch { // structured concurrency try { withContext(Dispatchers.IO) { fetchData() } } catch (e: Exception) { /* handle exception */ } }GlobalScope的协程生命周期与任何调用方无关——发起方销毁后协程仍在后台飘着既浪费资源又难以取消这是典型的泄漏源。结构化并发structured concurrency的原则是协程必须在其父作用域内、随父作用域同生共死viewModelScope或lifecycleScope、coroutineScope、supervisorScope保证页面销毁即整体取消withContext(Dispatchers.IO)负责线程切换而异常用try/catch就地收敛避免未处理异常冒泡到全局崩溃。六、规则 5类与对象设计问题没有利用 Kotlin 的语言特性导致冗余实现。检查要点Data class纯数据对象使用data class自动生成equals/hashCode/toString/copy/componentNSealed class/interface受限类型层级用sealed class配合when穷尽性检查编译期保证分支完备委托Delegation属性委托如by lazy或类委托by实现装饰器模式。反例class User(val name: String) { // manually implementing toString()/equals()... }改进data class User(val name: String) // standard methods auto-generated手写equals/hashCode/toString极易出 bug比如hashCode忘了纳入某个参与equals的字段导致 map 查找失效。data class由编译器按主构造函数属性统一生成这些方法行为一致且省心。同样地sealed class让when分支的穷尽性由编译器保障——未来新增子类型时未处理它的when会直接编译失败把漏分支从运行时错误变成编译期错误。七、规则 6资源管理与作用域函数问题资源未释放或作用域函数scope functions误用。检查要点使用use自动关闭文件/网络资源如FileInputStream().use { ... }作用域函数let、apply等应保持可读性避免过度嵌套。反例val file File(path) val reader BufferedReader(FileReader(file)) // forgot to call reader.close()改进File(path).inputStream().use { stream - // resource auto-closed }Java 时代finally { reader.close() }的样板代码在 Kotlin 中被use取代它接收一个Closeable保证代码块无论正常返回还是抛异常都会关闭资源。审查时重点看所有打开的文件流、Socket、数据库连接是否都通过use或useLines、useBufferedReader等变体管理。作用域函数方面let/run/with/apply/also各有其惯用场景——如apply适合对象初始化配置、let适合空值检查后操作滥用会导致it/this混乱嵌套过深时应抽成具名函数。八、规则 7性能陷阱问题隐藏的性能开销hidden performance overhead。检查要点内联函数高阶函数使用inline降低 lambda 开销但避免内联大型函数常量编译期常量用const val而非val避免在循环内创建对象如Regex实例。三点逐一展开inline将函数体在调用点展开消除 lambda 对应的匿名类对象分配。对高频调用的高阶函数如集合操作的回调收益明显但内联会放大字节码体积大函数内联会拖慢编译并增加方法体大小限制风险所以只适合小函数const val是真正的编译期常量会被内联进引用处、且可用于注解参数annotation arguments而普通val只是运行时只读属性。能用const val的地方编译期已知的字面量就不要用val循环内Regex(...)每次迭代都重新编译模式应提取为顶层private val pattern Regex(...)复用。九、规则 8Java 互操作Interoperability问题Java 代码调用 Kotlin 代码时出现兼容性问题。检查要点使用JvmStatic与JvmOverloads优化暴露给 Java 调用方的 API空安全注解使用Nullable/NonNull帮助 Java 侧识别可空性。原因在于Kotlin 的可空性、默认参数、伴生对象companion object等特性在 JVM 层面并没有一等公民的表达。若你的 Kotlin 代码会被 Java 调用需要主动铺桥默认参数在 Java 眼里不存在JvmOverloads会让编译器为每个默认参数组合生成重载方法伴生对象中的成员默认属于静态内部类实例JvmStatic才能生成真正的静态方法让 Java 用User.create()而非User.Companion.create()调用Kotlin 的可空类型对 Java 是无标注platform type的Nullable/NonNull或 JSR-305 注解能帮助 IDE 与静态分析工具在 Java 侧正确提示空值风险。十、规则 9其他关键点不可变性Immutability优先val而非var。不可变引用让数据流更可预测、天然线程安全、便于推理。只有当变量确实需要重新赋值时才用var字符串处理使用字符串模板Value: $value含${expr}表达式插值而非字符串拼接Value: value。模板更简洁、可读性更高编译器处理也更具确定性。这两点虽未给出正反例但在审查实践中出现频率极高——尤其var滥用是并发 Bug 的温床属于 Kotlin 审查的高性价比检查项。十一、验证与调试ocr rules check规则解析过程并不透明实际生效的规则可能与直觉不符例如项目里某个**/*.kt自定义规则拦截了系统规则。open-code-review 提供ocr rules check命令直接查看给定文件路径解析出的规则、来源层与匹配模式实现见 rules_cmd.go。# 查看 src/main/kotlin/com/example/UserService.kt 解析到的规则 ocr rules check src/main/kotlin/com/example/UserService.kt输出示例File: src/main/kotlin/com/example/UserService.kt Source: System built-in Pattern: **/*.{kt,kts} Rule: ──────────────────────────────────────── …kotlin.md 的完整内容… ────────────────────────────────────────若携带自定义规则文件ocr rules check --rule custom.json src/main/kotlin/com/example/UserService.kt此时Source会显示Custom (--rule)、Pattern显示你自定义的匹配模式。该命令背后调用rules.NewResolverResolveDetail与真实审查流程共享同一套解析逻辑因此检查结果即审查时的实际生效规则。仓库测试也印证了.kt/.kts的解析行为system_rules_test.go 中{app.kt, Null Safety}、{scripts/setup.kts, Null Safety}断言app.kt与setup.kts均解析到包含 Null Safety 的 kotlin.md 规则体另有{src/main/bar.kt, jvm-rule}验证项目级自定义规则可覆盖系统规则lib/**/*.kt的 include /**/tmp/**的 exclude 过滤也都有对应用例。十二、定制你的 Kotlin 审查策略内置kotlin.md是通用基线真实项目往往需要叠加团队规范。推荐做法是把自定义规则写入repoDir/.opencodereview/rule.json并提交入库{ rules: [ { path: **/*.{kt,kts}, rule: 团队附加要求所有 public API 必须显式标注 JvmOverloads若被 Java 调用禁止在循环体内创建 Regex 实例data class 属性一律使用 val。, merge_system_rule: true } ] }设置merge_system_rule: true后模型得到的提示词为System-Specific Rules即本文章讲解的 kotlin.md 全文 User-Specific Rules团队要求两部分内置空安全、协程等检查仍然强制保留。若不设置该字段则团队规则完全替换系统规则。其他层级同理~/.opencodereview/rule.json放个人全局偏好单次 PR 需要不同检查清单时用ocr review --rule ./security-only.json覆盖所有层级。规则文件中的rule字段既可以是内联文本也可以引用.md/.txt文件路径扩展名白名单 512KB 大小上限 路径穿越校验见 system_rules.go。结语kotlin.md是 open-code-review 内置 Kotlin 审查清单的完整形态从!!滥用、死代码、if-else链、集合中间对象、GlobalScope泄漏到 data class/sealed class、use资源管理、inline/const val性能、JvmOverloads互操作九个方向覆盖了 Kotlin 项目最常见的质量风险。它经由 system_rules.json 的**/*.{kt,kts}模式、go:embed内嵌分发与四层优先级链最终注入 LLM 提示词而ocr rules check让你能随时确认这份规则对某个文件是否真的生效。理解这份规则文档的每一处细节你就能更准确地预测 open-code-review 的审查行为并在此基础上叠加属于自己团队的 Kotlin 规范。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考