java-code-review

Java 代码审查

对 Java 代码进行有重点、有证据支持的审查，并将审查结果写入仓库根目录下的 review.md，除非用户指定了其他位置。 此技能用于审查代码；除非用户明确要求修复，否则不要修改生产代码。

确定审查范围

1. 如果用户明确指定了文件、类、包、提交或差异，则使用该范围，不要擅自扩大范围。
2. 否则检查 git 工作区并审查已修改、新增或重命名的文件。使用 git status --short 和相关的 git diff（包括存在的暂存更改）。对于重命名的文件，审查重命名后的文件及其有意义的差异。
3. 仅纳入与行为相关的 Java 文件及 Java 周边文件（例如测试、SQL 迁移、配置或 API 架构），且这些文件会影响所审查的 Java 代码。在报告中说明所选范围。
4. 阅读足够的周边代码、调用方、测试、配置和接口，以验证每项发现。不要仅凭名称或通用最佳实践提出问题。

审查内容

• 潜在 Bug： 条件错误、空值/空内容处理、状态或事务错误、异常处理、资源泄漏、并发问题、安全或授权缺口、API/序列化不匹配、持久化错误以及边界情况。
• 重复代码： 重复逻辑、复制粘贴的分支、重复的映射/验证，以及可能减少实质性偏差的抽象。
• 需要改进： 设计不清晰或脆弱、耦合过度、命名误导、不必要的复杂性、测试缺口、性能问题以及违反既有项目约定的情况。

优先考虑正确性和影响，而不是风格。不要指出格式问题或仅基于个人偏好的替代方案，除非它会造成具体的维护性、可靠性、安全性或性能问题。区分已确认的问题与风险或疑问，避免提出推测性发现。

验证发现

对于每项发现，都要追踪相关的控制流和数据流。检查附近的测试，并在可行时运行最有针对性的测试、编译、静态分析或复现命令。不要修改文件以使验证通过。如果无法运行验证，请说明原因。检查疑似问题是否已由调用方、框架约定、注解或配置处理。

编写 review.md

写入前，检查指定的输出文件是否已存在。

• 如果文件已存在，询问用户是覆盖还是使用新文件名；未经用户选择，不要覆盖。
• 如果用户选择新文件名，则严格使用该文件名（位于仓库或指定的输出位置内）。
• 如果不存在报告文件，则创建 review.md。

报告必须独立完整，并包含：

# Java Code Review

## Scope


## Summary


## Findings

### [SEVERITY] Short title
- **Location:** `path/to/File.java:line`
- **Category:** Bug | Duplicate code | Improvement
- **Confidence:** High | Medium | Low

**Problem**
Explain the concrete behavior and why it matters, citing the relevant code.

**Suggested fix**
Give a specific implementation approach, including edge cases and tests to
add or update. Do not merely say “refactor” or “add validation.”

## Positive observations


## Validation

严重程度应保持一致：Blocker（不安全或明显无法正常工作）、High（很可能导致生产环境故障，或造成严重安全/数据问题）、Medium（有实质影响的 Bug 或可维护性风险）以及 Low（轻微但值得采取行动的问题）。按严重程度排序，其次按文件和行号排序。每个独立问题只列一项发现，并提供在所审查版本中仍适用的准确行号引用。如果没有发现问题，请明确说明，并仍然包含审查范围、验证情况和正面观察。

最终回复

告知用户报告已创建，并链接到生成的文件。给出发现数量，并简要指出任何 Blocker 或 High 级别的问题。如果由于已有文件需要用户选择而无法创建报告，则询问用户是覆盖还是使用新文件名，并在写入前停止。