技能介绍

要解决什么问题

团队接手或长期演进的 Spring Boot + MyBatis 项目，常见痛点是目录层级混乱、Controller/Service/Mapper 职责交叉、配置散落在各处，以及命名各写各的。这类结构不会立刻报错，但会增加 code review 成本、合并冲突和新人上手时间。

本技能面向「把现有项目对齐业界常见分层约定」，而不是替你做业务重构或框架选型。

技能如何工作

整体流程可以概括为：扫描 → 报告 → 标准骨架与配置参考 → 按需迁移。

项目扫描分析：扫描当前仓库，输出当前目录结构、识别出的问题（例如类放错包、命名不符合约定），以及建议的迁移路径。
生成标准结构：给出与约定一致的分层目录与配置文件布局，便于你对照现有代码做手动或半自动调整。
配置与骨架资源：

- references/ 下的模板说明：mybatis-config.md、redis-config.md、kafka-config.md、naming-conventions.md
- assets/project-template/ 可作为新项目的起点，改包名与配置后直接开发

命名约定（摘要）：根包 com.{公司}.{项目}，子包按 controller、service、dao、entity、dto、vo、config、util 划分；类名如 XxxController、XxxService/XxxServiceImpl、XxxMapper；Controller 方法倾向 getXxx/createXxx 等与 HTTP 语义对齐，Service 用业务语义，Mapper 用 selectXxx/insertXxx 等数据库操作命名。

适用边界与注意点

适合：已有 Spring Boot + MyBatis 代码需要统一结构；或从零开新项目并希望直接采用同一套骨架与命名规范。
不适合：仅想生成 CRUD、做性能调优、或替换为 JPA/其他 ORM——本技能聚焦结构与规范，不覆盖这些目标。
分析报告给出的是建议；实际迁移仍需结合模块边界、测试与发布节奏，避免一次性大挪移导致难以回滚。

截图预览

使用场景

接手他人维护的 Spring Boot + MyBatis 仓库，需先扫描并列出类放错包、命名不规范等问题，再排期分批重构。
从零新建后端服务时，以 `assets/project-template/` 为起点，改根包名与数据源等配置后直接开发，避免从旧仓库拷贝混乱目录。
线上项目 MyBatis、Redis、Kafka 配置写法不统一，对照 `references/` 下模板整理 `application.yml` 与 MyBatis 相关文件。
大版本或模块合并前，先跑结构扫描生成迁移建议，再按报告把 Controller、Service、Mapper 迁到约定包路径。