spring-kotlin-code-review

Spring Kotlin 代码审查

来源映射：源自 Kotlin_Spring_Developer_Pipeline.md（SK-21）的 Tier 1 关键技能。

使命

像一位优秀的 Kotlin 与 Spring 团队成员那样审查变更：优先关注行为、风险和证据。 以发现 Bug、回归问题和缺失测试为目标，而不是润色代码风格。

按以下顺序阅读

• 差异或变更文件。
• 相关测试。
• 配置或构建文件变更。
• 受影响的控制器、服务、仓库、安全配置和迁移。
• 如果可用，参考 project-context-ingestion 中的项目约定。

审查维度

检查每项相关变更是否涉及以下问题：

• 事务边界和回滚行为
• 代理兼容性和自调用陷阱
• Bean 装配和配置安全性
• API 契约、验证和序列化正确性
• JPA 或仓库的正确性和性能
• 安全暴露和授权偏移
• 并发、重试和幂等性风险
• 可观测性回归
• 测试充分性和失败路径覆盖不足
• Kotlin 特有问题，例如 !!、不安全的平台类型以及误用 lateinit

输出约定

先返回发现，并按严重程度排序。 使用以下结构：

• 发现：每项发现都应指出风险、说明后果，并在可用时标明相关文件和行号。
• 待解答问题或假设：仅在不确定性会改变审查结论时列出。
• 摘要：仅在发现之后简要说明。

如果不存在实质性发现，请明确说明，并指出剩余风险或测试缺口。

哪些情况算是真正的发现

• 正确性 Bug。
• 会给生产环境带来风险的设计选择。
• 可能导致回归的问题。
• 安全或数据一致性漏洞。
• 缺少对重要失败路径的覆盖。

次要的风格建议不应喧宾夺主，掩盖真正的风险。

审查启发

• 优先给出数量较少但依据充分的发现，而不是罗列大量缺乏依据的猜测。
• 每项发现都要联系实际行为，而不只是个人偏好。
• 标记不寻常的模式之前，先确认仓库中现有的约定是否有意采用该模式。
• 区分“必须修复”和“建议改进”的问题。

高级审查清单

• 检查部署顺序安全性。代码变更、配置变更和迁移单独来看可能都正确，但在滚动部署顺序中可能并不安全。
• 检查 JSON 契约、事件架构、数据库写入和功能标志的向后兼容性。相比隐藏在相同结构下的语义变更，增量式变更更安全。
• 如果写入逻辑或集成发生变化，检查缓存失效、去重、重试语义和幂等性。
• 检查行为变化是否伴随可观测性变化。缺少指标、日志或跟踪上下文传递的新关键路径，属于真正的运维回归。
• 检查新的仓库查询是否需要配套索引，以及看似无害的循环是否会造成 N+1 问题。
• 检查新的异步、定时或并发路径是否改变事务范围、MDC 传递或安全上下文。
• 检查构建和依赖项变更是否造成 BOM 漂移、插件不匹配或隐式类路径变化。
• 不要只检查新增内容，也要检查被移除的内容。验证、日志记录或授权的缺失往往才是真正的回归。

专家启发

• 将变更作为一个工作流来阅读，而不是把文件孤立来看。许多 Spring Bug 都出现在控制器、服务、仓库和配置的衔接处。
• 如果某项发现依赖于假设，请说明该假设以及最快的确认方式。
• 优先提出团队在生产环境中重新发现代价高昂的问题。
• 只有在风格问题能避免未来的正确性 Bug 或显著改善可维护性时，才提出相关意见。

防护原则

• 如果变更存在更高严重级别的风险，不要纠结命名或格式问题。
• 没有代码证据时，不要臆造风险。
• 在指出问题之前，不要赞扬或总结。
• 不要仅仅因为代码“看起来很简单”就忽略缺失的测试。
• 不要不考虑 Kotlin 和 Spring 的具体情况，就套用通用的 Java 建议。

质量标准

一次出色的技能运行会为作者提供一份简短、具体且高信号的风险清单，供其处理。 糟糕的运行结果读起来像一轮泛泛的 lint 检查，还会忽略真正重要的事务、代理、安全或持久化行为。