Java 编码规范

将这个 skill 视为 Java 17+ / Spring Boot 项目的简明工作卡。SKILL.md 只保留流程和路由，具体规则按需加载 references/ 下的参考文件。

使用原则

• 仓库内规则优先于本 skill。若 AGENTS.md、CLAUDE.md、本地格式化配置或相邻代码与本 skill 冲突，优先遵循仓库约定；只有当冲突会影响结果时，再明确指出。
• 不要为了满足本 skill 而大规模重构无关代码。优先贴近现有模式，除非当前实现已经带来真实的正确性、安全性、事务或可维护性风险。
• 规则要尽量具体、可检查。维护本 skill 时，始终追问一句：删掉这条后，AI 是否更容易犯真实错误？
• 禁止项要配上推荐替代方案。例如：不要用字段注入；优先使用构造器注入，通常配合 Lombok @RequiredArgsConstructor。
• 机械性规则尽量交给工具。优先依赖 formatter、Checkstyle、Spotless、测试、CI 或 hooks，不要只靠自然语言约束格式。

工作流程

编写或重构代码时

1. 先看项目上下文：构建文件、本地说明文件、formatter/lint 配置、包结构以及相似类的现有写法。
2. 只加载当前改动真正需要的参考文件，按下方“参考路由”选择。
3. 控制改动面，尽量只改行为相关部分，不顺手做无关清理。
4. 把逻辑放到正确层级：

Controller 负责路由、认证边界、校验注解和响应转换； Service 负责业务编排； Manager 负责事务和 DAO 组合； DAO/Mapper 负责持久化。

1. 用最小但有效的命令验证：优先跑定向测试、模块编译、formatter 或静态检查；如果没跑，要说明原因。

代码评审时

1. 先看 bug 和风险，不要先盯风格细节。
2. 按严重程度排序问题，并尽量给出文件/行号引用。
3. 每个问题都说明：违反了什么规则、为什么重要、推荐怎么修。
4. 风格问题只有在会带来维护成本，或与仓库工具链冲突时才提。
5. 如果没有发现问题，要明确说明，同时补充剩余的测试或验证缺口。

回答规范类问题时

优先按这个结构回答：规则、原因、示例、以及仓库内是否存在本地覆盖约定。

参考路由

| 需求 | 加载文件 | | --- | --- | | Java 格式、导入、括号、缩进、换行、switch、注解、修饰符、Javadoc、命名 | references/google-style.md | | 项目结构、JavaBean 后缀、Optional、Stream、泛型、不可变性、现代 Java 特性 | references/code-style.md | | 模块化目录、Controller/Service/Manager/DAO 分层、URL 规范、@Transactional、设计模式、统一响应 | references/architecture.md | | 异常、日志、性能、线程池、远程调用、安全、测试、数据库设计 | references/best-practices.md |

核心默认规则

• 格式：2 空格缩进，不用 Tab，100 列限制，K&R 大括号风格，不用通配符导入，修饰符顺序标准化，可见 API 在有必要时补 Javadoc。
• 命名：类使用 UpperCamelCase，方法/字段使用 lowerCamelCase，常量使用 UPPER_SNAKE_CASE，包名全小写且不用下划线，项目名全小写并使用中划线。
• API 边界：不要直接暴露 Entity。请求用 Form，返回用 VO，跨层传输用 DTO，内部业务对象用 BO。BO 不应出现在 Controller API 中。
• 布尔字段：优先使用 xxxFlag / xxx_flag，避免 isXxx 字段，以免序列化和 RPC 映射歧义。
• 参数数量：单个方法参数尽量不超过 5 个；超过时优先封装为请求对象或值对象。
• URL 风格：默认跟随仓库现有约定。若仓库没有明确约定，本 skill 默认偏向非 RESTful 的 GET/POST /module/submodule/action，并且把路由注解写在方法上，便于搜索。
• 文档注解：遵循仓库当前使用的 Swagger/OpenAPI 体系。若项目使用 Swagger @ApiOperation，需要沿用既有 author 习惯；若项目使用 springdoc，则跟随本地 @Operation 写法。

分层默认规则

• Controller：不写业务逻辑，不做数据组装，不直接访问 DB/缓存/MQ。只有在请求边界层，且项目采用请求线程上下文时，才在这里获取当前用户。
• Service：负责业务编排和校验；大 Service 按 use case 拆分。
• Manager：默认把 @Transactional(rollbackFor = Exception.class) 放在这里，负责 DAO 组合和第三方平台细节封装，并尽量缩小事务范围。
• DAO/Mapper：只做持久化。对于采用这套约定的 MyBatis-Plus 项目，优先 XML mapper SQL，避免 Wrapper 查询构造器，常量通过参数传入，业务逻辑不要写进 XML。

没有本地覆盖时不要做的事

• 不要在数据库事务里调用外部 HTTP、LLM、S3、MQ、邮件或其他慢速远程接口。事务前准备数据，必要时在提交后触发副作用。
• 不要依赖同类内部调用触发 @Transactional；应把事务方法移动到另一个 Spring Bean，通常是 Manager，或使用仓库既有代理方案。
• 不要创建静态异常实例，否则堆栈信息会失真。
• 不要写空的 catch (Exception e) {}；要么处理、要么带上下文包装、要么明确说明为何可以忽略。
• 不要在同一层既记录日志又继续抛出同一个异常，除非该层就是最终处理层。
• 不要把 N+1 数据库调用或远程调用藏进 Stream 或循环里；应先批量查，再在内存中组装。
• 不要硬编码密钥、Token、供应商 base URL；使用配置与仓库既有的 URL 校验/客户端工厂。
• 不要在生产路径使用 Executors.newFixedThreadPool() 或 newCachedThreadPool()；要显式创建带边界队列、线程名、监控和关闭逻辑的 ThreadPoolExecutor Bean。

评审检查清单

架构与 API：

• Controller / Service / Manager / DAO 职责是否清晰分离。
• 请求/响应边界是否使用 Form / VO / DTO 和统一响应包装。
• 是否遵循本地 URL 与 Swagger/OpenAPI 规范。

事务与持久化：

• 需要事务的方法是否正确使用 rollbackFor = Exception.class。
• 事务内是否混入远程调用、大循环或慢操作。
• DAO/Mapper 是否保持持久化职责，没有出现 N+1 访问。

数据模型与 Java 风格：

• JavaBean 后缀与布尔 flag 规则是否正确。
• 方法是否足够短、可读，参数数量是否控制在 5 个以内。
• Optional、Stream、record、switch expression 是否在提升可读性时才使用。

异常、日志与安全：

• 领域异常是否包含足够上下文，且不是静态实例。
• 日志是否使用 SLF4J，保留堆栈，避免重复记录，并对敏感数据做脱敏。
• 外部 URL、密钥和用户输入是否走本地安全工具或约束。

测试与验证：

• 关键分支、边界和异常路径是否有聚焦测试覆盖。
• 是否运行了最小但有意义的编译/测试/lint 命令；若未运行，是否说明原因。

Skill 维护规则

维护这个 skill 时，遵循与优秀 CLAUDE.md / AGENTS.md 相同的原则：

• 让 SKILL.md 只承担路由和执行层角色；长示例和细则放入 references/。
• 只有当某条规则长期有效、足够通用、并且确实能减少重复错误时，才把它固化进来。
• 删除模糊规则，例如“写出干净代码”，除非它包含明确检查点或替代方案。
• 如果某条规则本可以由 formatter、linter、hook、测试或 CI 强制执行，优先记录工具和验证命令，而不是只写成文字说明。
• 对 skill 做了较大修改后，用 skill-creator 的验证流程再检查一遍。