尧图网站建设 
简介针对数据库表结构常见的重复增删改查操作这套面向 Java 后端的本地代码生成工具提供了高效的一键生成方案。工具连接数据库后读取指定数据表信息自动生成包括控制层、服务层、数据访问层、实体类及 XML 映射在内的完整代码并预置 Swagger 与 MyBatis-Plus 注解让接口文档和 ORM 配置同步就绪开发者只需做少量修改即可嵌入现有工程。压缩包共收录二十五个文件其中十八个为 Java 源码文件两个为 XML 映射文件另含 JSON 配置、可执行 JAR、启动脚本、示例建表 SQL 与操作说明打包后整体大小约为二十四点五一兆字节文件组织清晰方便按模块取用。已有 1934 人学习下载工具无需集成到业务项目本地运行即可生成带注释的代码复制到项目路径并调整配置即可覆盖大多数增删改查场景。随包附带详细的使用说明逐项解释数据库地址、用户名、密码、包名、数据表列表及输出目录等关键配置并提供可直接导入的示例表结构按照步骤操作即可快速验证生成效果切实提升日常开发效率。1. 为什么我建议用本地代码生成器先跑通再改代码数据库表一多Java CRUD 代码就变成了体力活。我见过不少项目几十张表对应的 controller、service、entity、mapper 全靠手敲改一个字段名要牵动五六个文件。这也是我拿到这套基于数据库 SQL 生成 Java 代码的生成器之后第一时间跑通的原因——它本地执行读一遍数据库连接信息按表批量输出带注释和 Swagger 注解的增删改查代码。适合谁日常写 Spring Boot MyBatis-Plus 的后端、手里堆着表等出接口的以及不想把生成器依赖打进项目工程的人。双击运行生成完删掉 jar 也不影响项目这种用完即走的方式对存量工程最友好。2. 跑通本地生成器json 配置和 start.bat 才是入口这个工具最容易被忽略的一点是它不需要导入工程。它不是 Maven 插件也不是 IDEA 里装的代码生成面板而是一个独立 jar。运行结束代码落到你指定的 outdir剩下的活儿就是复制进项目、修修改改。所以它的学习曲线很短难点不在 Java 代码而在那三个配置文件的配合流程mybatisplus.json 决定生成规则start.bat 决定启动方式test.sql 决定验证数据。2.1 工具定位为什么生成器把宝押在 MyBatis-Plus 上生成器输出的实体带 TableName、TableId、TableField 注解mapper 继承 BaseMappermapper.xml 保留扩展位。押注这套组合的原因是 MyBatis-Plus 对单表 CRUD 的封装足够彻底插入、按 ID 删除、按 ID 查询、分页这些高频操作在 BaseMapper 接口里已经定义好了生成器只需要把表结构映射成实体类通用方法自动继承。业务里真正要手动写的只有带条件的分页查询和跨表逻辑。这也决定了生成器的边界它擅长单表的“标准动作”不擅长复杂 SQL 和业务状态机。拿到手先用 test.sql 验证一轮再批量处理业务表是最稳的路径。我一般不建议上来就把几十张表全部塞进 tableList先跑一张表确认输出符合预期再扩大范围出问题了也好定位。2.2 mybatisplus.json生成器的控制面板先看一个完整配置示例{ outdir: D:/codegen/output, jdbcUrl: jdbc:mysql://127.0.0.1:3306/demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai, jdbcUser: root, jdbcPwd: 123456, packageName: com.example.demo, tableList: user,orders }参数必填作用outdir是生成代码的落地目录必须绝对路径jdbcUrl是数据库连接串决定读哪台库的表结构jdbcUser是连接数据库的用户名jdbcPwd是连接数据库的密码packageName是生成代码的包名前缀tableList是要生成的表名多个表用英文逗号隔开参数看起来直白实际上有三处容易出问题。outdir 必须写绝对路径Windows 下建议用正斜杠D:/codegen/output 这种写法比 D:\codegen\output 少踩很多转义坑。jdbcUrl 里的时间戳参数 serverTimezone 不能少MySQL 8 以后不指定会直接报连接错误。packageName 要按你项目的实际包名配置生成出来的文件会按 com/example/demo/controller、com/example/demo/entity 这样的目录结构摆放。提示jdbcPwd 是明文存储的这个文件建议只放本机提交到 Git 之前先确认没有把密码带进仓库。2.3 start.bat双击之前先看这三行start.bat 的核心其实只有一行命令但这一行决定了整个工具能不能跑起来echo off java -jar mybatisplus-generator.jar --config.pathD:/codegen/mybatisplus.json pauseecho off 关闭命令回显避免窗口里刷一堆无关字符。--config.path 指向本地实际的 mybatisplus.json 路径资源包里默认是相对路径我一般会改成绝对路径用正斜杠。pause 让窗口运行结束后停住否则生成失败你也看不到日志窗口一闪而过就只剩一头雾水。执行顺序我习惯固定成四步先把 test.sql 导入数据库再改 mybatisplus.json再改 start.bat最后双击运行。运行起来之后控制台会打印连接的库名、处理到的表名以及每个文件生成的位置。看到类似 generate success 的日志说明生成器跑通了去 outdir 目录确认文件是否存在。这里有个用命换来的细节jar 包的完整路径不要带空格比如 D:\Program Files\ 这种路径java -jar 执行时引号处理不当就会报“找不到或无法加载主类”。把工具整个放到一个纯英文、无空格的目录下能省掉一半的启动问题。3. 生成结果拆解六个文件各自拿了什么活生成器输出的文件不是一堆乱码每一类都有明确职责。先把六类文件的定位看清楚复制进项目之后才知道哪里该改、哪里不该动。生成文件核心内容落地后重点改哪里entity表字段映射、注释、Swagger 注解补充业务字段说明mapper继承 BaseMapper 的接口基本不用动mapper.xmlResultMap 与预留 SQL 位复杂查询时扩展repository数据访问门面接口加缓存或切面时用service业务接口与实现类补业务方法、事务边界controllerREST 接口按项目统一返回体调整3.1 entity表结构到 Java 字段的映射实体是整个生成链路的地基字段对不上后面 Mapper 和 XML 全得返工。生成的实体长这样Data TableName(user) ApiModel(value UserEntity, description 用户表) public class UserEntity { TableId(value id, type IdType.AUTO) ApiModelProperty(value 主键ID) private Long id; TableField(user_name) ApiModelProperty(value 用户名) private String userName; }关键点有两个。第一TableName 显式声明表名TableId 标记主键并指定自增策略TableField 把下划线字段 user_name 映射到驼峰属性 userName生成器在读取数据库字段后会自动做这个转换不需要手写。第二每个字段都带 ApiModelProperty 注解这为后面 Swagger 文档自动生成铺好了路——接口文档里的字段说明不需要再单独维护。用 MyBatis-Plus 这套注解实体可以省掉大量手写的 XML 映射配置。需要留意的是数据库字段类型和 Java 类型之间的映射bigint 对应 Longvarchar 对应 Stringdatetime 生成的是 LocalDateTime如果项目里还在用 java.util.Date生成后批量替换一下类型即可。3.2 mapper 与 repository数据访问入口的分工public interface UserMapper extends BaseMapperUserEntity { }mapper 接口继承了 BaseMapper 之后插入、按 ID 删除、按 ID 查、按条件统计这些方法全都有了。这是 MyBatis-Plus 省代码的核心——单表操作不需要在 XML 里写 SQL。生成出来的 mapper.xml 主要起两个作用一是给复杂查询预留扩展位二是定义 ResultMap 和基础查询列日常 CRUD 几乎用不到但写多表关联时不用回头补映射。repository 这层是这个生成器比较特别的地方它不是 MyBatis-Plus 框架强制要求的更像是数据访问门面。效果是把 mapper 和 service 隔开方便在调度层统一加缓存、加事务注解。常见写法是Repository public interface UserRepository extends UserMapper { }继承 UserMapper既拿到 BaseMapper 的全部能力又在语义上独立出来。后面 service 层依赖 UserRepository 而非 UserMapper想替换或者加切面的时候改动面就只有 repository 这一条线。如果你的项目没有分层习惯直接删掉 repository 也不会影响编译。3.3 controller 与 service接口到数据库的完整链路RestController RequestMapping(/user) Api(tags 用户管理) public class UserController { Autowired private UserService userService; ApiOperation(分页查询) GetMapping(/page) public Object page(RequestParam Integer pageNo, RequestParam Integer pageSize) { return userService.page(pageNo, pageSize); } ApiOperation(新增用户) PostMapping(/add) public Object add(RequestBody UserEntity entity) { return userService.add(entity); } }controller 里每个方法都带 ApiOperation路径按表名自动生成入参直接绑定实体。生成器在返回类型上通常给出的是通用结构落到项目里按你现有的 Result 或 R 包装类改一下签名即可这个工作量很小。service 接口和实现类则把业务方法聚在一起分页、新增、修改、删除、详情五个方法各占一个文件位置。整套串起来就是controller 收参 → service 写业务 → repository/mapper 落库。看到这里你就明白了生成器不是在造轮子而是把表和 Java 类之间的胶水代码批量糊好了。你要做的是在 service 实现类里补业务校验、补事务边界把生成器的“通用”改成你项目的“专用”。4. 完整实战用 test.sql 从建表走到项目落地前面拆完了文件职责这一章把整个流程走一遍。资源包自带 test.sql这就是用来验证生成器是否跑通的试金石。4.1 先建表test.sql 导入到本地数据库用 MySQL 命令行演示导入mysql -uroot -p123456 test.sql导入后确认表是否建成SHOW TABLES;看到测试表出现在列表里再执行 DESC 看一眼结构和主键。这一遍确认特别值得做后面生成器连库读表结构时表名、主键、字段类型的问题会先在这里暴露一次总比生成完代码发现主键类型不对要省事。4.2 改配置生成outdir 指到你的工程目录接下来把 mybatisplus.json 里的 outdir 指到一个临时目录或者直接指向工程源码目录。常见做法是先指到独立目录生成完检查文件没问题再复制进工程避免生成失败时污染现有源码。{ outdir: D:/workspace/my-project/src/main/java, jdbcUrl: jdbc:mysql://127.0.0.1:3306/demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai, jdbcUser: root, jdbcPwd: 123456, packageName: com.company.order, tableList: user }outdir 直接指到 src/main/java生成器会自动按包名展开目录packageName 一定要改成工程的实际包名 com.company.order。双击 start.bat窗口里能看到连接的库名、开始生成的表名以及每个文件的输出路径。生成完到 outdir 下检查目录结构应该和工程包名对应src/main/java/com/company/order ├── controller/UserController.java ├── service/UserService.java ├── service/impl/UserServiceImpl.java ├── repository/UserRepository.java ├── mapper/UserMapper.java ├── mapper/UserMapper.xml └── entity/UserEntity.java注意如果工程里已经有同名文件备份好再生成同名文件会被覆盖。4.3 复制进项目改掉这几处就能编译生成完六类文件复制到工程目录后还差最后几步。第一步确认 Result、分页对象这些公共类在工程里存在没有就按项目现有返回格式调整 controller 的方法签名。第二步在 service 实现类上补上 Service 和事务注解生成器倾向于只出骨架业务注解这类涉及项目约定的东西通常要自己补Service public class UserServiceImpl extends ServiceImplUserRepository, UserEntity implements UserService { }Service 让 Spring 能扫描到这个实现类ServiceImplUserRepository, UserEntity 是 MyBatis-Plus 提供的快速实现方式IService 里自带的 save、removeById、page 等方法直接可用。第三步检查 swagger 依赖是否已在 pom 里Api、ApiOperation 注解类缺失会导致编译失败dependency groupIdio.springfox/groupId artifactIdspringfox-swagger2/artifactId version2.9.2/version /dependency把项目启动起来访问 Swagger 页面能看到生成接口的路径描述和字段说明说明整条链路已经通了。从建表到接口文档出现差不多十分钟比手写快出一个量级。5. 代码生成器避坑指南五个翻车点与排查方法工具虽然简单跑起来之后的坑一点都不少。下面五条全是实操中真实遇到的按启动阶段和生成结果阶段分开说。5.1 启动阶段的三个翻车点现象一双击 start.bat 窗口一闪而过什么日志都没留下。原因多半是 java 环境变量没配好或者 jar 路径带中文或空格。解决先在命令行手动执行 java -version 确认 JDK 1.8 及以上再检查 start.bat 里的 jar 路径改成绝对路径并确保目录无中文无空格。现象二控制台报 Access denied for user。原因jdbc 账号权限不足生成器要读 information_schema 里的表结构普通业务账号经常没有这个权限。解决给账号授权或者首次复现时直接用 root 跑一次生成。不建议长期用 root但快速验证时用 root 没问题。现象三报 Unknown database。原因jdbcUrl 里的库名和 test.sql 实际导入的库名不一致。解决SHOW DATABASES 确认库名回填到 jdbcUrl 中。这一步看着低级实际最常见因为 test.sql 里的建表语句可能带了 USE 关键字直接导入到默认库和你配置的库对不上。5.2 生成结果的两个翻车点现象四生成的实体字段全乱下划线没转驼峰注释丢了一半。原因jdbcUrl 缺少 characterEncoding 参数或者连接串里没开 useInformationSchema。解决在 jdbcUrl 末尾补上 characterEncodingutf8重新生成。这套代码生成器的字段解析依赖数据库驱动读表注释连接串有问题会直接体现在注释丢失、字段错位这些症状上。这个坑最隐蔽生成的代码看起来完整但 Swagger 文档里全是空注释排查方向一直以为是生成器坏了最后发现是数据库连接串的锅。现象五tableList 写了多个表但只生成了一张。原因分隔符用了中文逗号或者行尾多了空格和换行。解决改用英文逗号并检查 tableList 的值不要带多余空白。配置文件的坑就属于这种玄学——肉眼看起来一样解析就差一个字符。所以我现在跑完生成的第一件事就是抽查一张表的 entity 注释是否完整、字段顺序是否符合预期确认没问题再批量复制进项目。别等到编译报错再倒回去查 json那会浪费一倍时间。6. 更进一步改模板与差异化验证生成器跑通只是第一步真正让工具长在自己手上的是改模板。jar 包里常见的模板格式是 Velocity 的 .vm 文件模板里混着 Java 代码和占位符变量。比如想给所有 controller 统一加一个 Validated 校验注解直接改 vm 模板再重新执行 jar 生成所有表都会带出来。这个能力特别适合团队有统一规范的时候——把规范烧进模板比写文档再让人遵守靠谱得多。改模板的操作不复杂用压缩工具打开 jar找到 resources 目录下的模板文件替换后重新打包或者放在外部目录覆盖加载。唯一要注意的是模板里的变量语法不要改错比如字段遍历的 foreach 结构一旦写错生成出来的 Java 文件直接编译不过。改之前先备份原模板是小成本换大安稳的习惯。验证方法我说一个习惯每次生成新一批代码时先拿一张表和上一版做 diff。用 IDEA 的 Compare 或 git diff 看实体和 controller 的变化判断是预期的规范变更还是意外改动。如果只是调整了字段位置说明模板改对了如果出现方法被删、注解丢失回头查模板里的遍历逻辑。最后提醒一点生成器适合处理八成的常规 CRUD剩下两成的业务个性化逻辑不要硬往生成器里塞——比如带复杂状态机的订单流程、多表聚合查询这些还是手写更清晰。工具的价值是帮你省掉重复劳动的时间不是替代思考。从那以后我每次拿到新的表结构都强制走一遍建测试表、生成、抽查 entity 注释、编译验证的流程项目里的同事照着这个步骤做再没返工过。希望这篇笔记能让你少踩几个坑顺利把工具用起来。本文还有配套的精品资源点击获取 基于数据库 SQL 的本地代码生成器：Spring Boot CRUD 实战
简介针对数据库表结构常见的重复增删改查操作这套面向 Java 后端的本地代码生成工具提供了高效的一键生成方案。工具连接数据库后读取指定数据表信息自动生成包括控制层、服务层、数据访问层、实体类及 XML 映射在内的完整代码并预置 Swagger 与 MyBatis-Plus 注解让接口文档和 ORM 配置同步就绪开发者只需做少量修改即可嵌入现有工程。压缩包共收录二十五个文件其中十八个为 Java 源码文件两个为 XML 映射文件另含 JSON 配置、可执行 JAR、启动脚本、示例建表 SQL 与操作说明打包后整体大小约为二十四点五一兆字节文件组织清晰方便按模块取用。已有 1934 人学习下载工具无需集成到业务项目本地运行即可生成带注释的代码复制到项目路径并调整配置即可覆盖大多数增删改查场景。随包附带详细的使用说明逐项解释数据库地址、用户名、密码、包名、数据表列表及输出目录等关键配置并提供可直接导入的示例表结构按照步骤操作即可快速验证生成效果切实提升日常开发效率。1. 为什么我建议用本地代码生成器先跑通再改代码数据库表一多Java CRUD 代码就变成了体力活。我见过不少项目几十张表对应的 controller、service、entity、mapper 全靠手敲改一个字段名要牵动五六个文件。这也是我拿到这套基于数据库 SQL 生成 Java 代码的生成器之后第一时间跑通的原因——它本地执行读一遍数据库连接信息按表批量输出带注释和 Swagger 注解的增删改查代码。适合谁日常写 Spring Boot MyBatis-Plus 的后端、手里堆着表等出接口的以及不想把生成器依赖打进项目工程的人。双击运行生成完删掉 jar 也不影响项目这种用完即走的方式对存量工程最友好。2. 跑通本地生成器json 配置和 start.bat 才是入口这个工具最容易被忽略的一点是它不需要导入工程。它不是 Maven 插件也不是 IDEA 里装的代码生成面板而是一个独立 jar。运行结束代码落到你指定的 outdir剩下的活儿就是复制进项目、修修改改。所以它的学习曲线很短难点不在 Java 代码而在那三个配置文件的配合流程mybatisplus.json 决定生成规则start.bat 决定启动方式test.sql 决定验证数据。2.1 工具定位为什么生成器把宝押在 MyBatis-Plus 上生成器输出的实体带 TableName、TableId、TableField 注解mapper 继承 BaseMappermapper.xml 保留扩展位。押注这套组合的原因是 MyBatis-Plus 对单表 CRUD 的封装足够彻底插入、按 ID 删除、按 ID 查询、分页这些高频操作在 BaseMapper 接口里已经定义好了生成器只需要把表结构映射成实体类通用方法自动继承。业务里真正要手动写的只有带条件的分页查询和跨表逻辑。这也决定了生成器的边界它擅长单表的“标准动作”不擅长复杂 SQL 和业务状态机。拿到手先用 test.sql 验证一轮再批量处理业务表是最稳的路径。我一般不建议上来就把几十张表全部塞进 tableList先跑一张表确认输出符合预期再扩大范围出问题了也好定位。2.2 mybatisplus.json生成器的控制面板先看一个完整配置示例{ outdir: D:/codegen/output, jdbcUrl: jdbc:mysql://127.0.0.1:3306/demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai, jdbcUser: root, jdbcPwd: 123456, packageName: com.example.demo, tableList: user,orders }参数必填作用outdir是生成代码的落地目录必须绝对路径jdbcUrl是数据库连接串决定读哪台库的表结构jdbcUser是连接数据库的用户名jdbcPwd是连接数据库的密码packageName是生成代码的包名前缀tableList是要生成的表名多个表用英文逗号隔开参数看起来直白实际上有三处容易出问题。outdir 必须写绝对路径Windows 下建议用正斜杠D:/codegen/output 这种写法比 D:\codegen\output 少踩很多转义坑。jdbcUrl 里的时间戳参数 serverTimezone 不能少MySQL 8 以后不指定会直接报连接错误。packageName 要按你项目的实际包名配置生成出来的文件会按 com/example/demo/controller、com/example/demo/entity 这样的目录结构摆放。提示jdbcPwd 是明文存储的这个文件建议只放本机提交到 Git 之前先确认没有把密码带进仓库。2.3 start.bat双击之前先看这三行start.bat 的核心其实只有一行命令但这一行决定了整个工具能不能跑起来echo off java -jar mybatisplus-generator.jar --config.pathD:/codegen/mybatisplus.json pauseecho off 关闭命令回显避免窗口里刷一堆无关字符。--config.path 指向本地实际的 mybatisplus.json 路径资源包里默认是相对路径我一般会改成绝对路径用正斜杠。pause 让窗口运行结束后停住否则生成失败你也看不到日志窗口一闪而过就只剩一头雾水。执行顺序我习惯固定成四步先把 test.sql 导入数据库再改 mybatisplus.json再改 start.bat最后双击运行。运行起来之后控制台会打印连接的库名、处理到的表名以及每个文件生成的位置。看到类似 generate success 的日志说明生成器跑通了去 outdir 目录确认文件是否存在。这里有个用命换来的细节jar 包的完整路径不要带空格比如 D:\Program Files\ 这种路径java -jar 执行时引号处理不当就会报“找不到或无法加载主类”。把工具整个放到一个纯英文、无空格的目录下能省掉一半的启动问题。3. 生成结果拆解六个文件各自拿了什么活生成器输出的文件不是一堆乱码每一类都有明确职责。先把六类文件的定位看清楚复制进项目之后才知道哪里该改、哪里不该动。生成文件核心内容落地后重点改哪里entity表字段映射、注释、Swagger 注解补充业务字段说明mapper继承 BaseMapper 的接口基本不用动mapper.xmlResultMap 与预留 SQL 位复杂查询时扩展repository数据访问门面接口加缓存或切面时用service业务接口与实现类补业务方法、事务边界controllerREST 接口按项目统一返回体调整3.1 entity表结构到 Java 字段的映射实体是整个生成链路的地基字段对不上后面 Mapper 和 XML 全得返工。生成的实体长这样Data TableName(user) ApiModel(value UserEntity, description 用户表) public class UserEntity { TableId(value id, type IdType.AUTO) ApiModelProperty(value 主键ID) private Long id; TableField(user_name) ApiModelProperty(value 用户名) private String userName; }关键点有两个。第一TableName 显式声明表名TableId 标记主键并指定自增策略TableField 把下划线字段 user_name 映射到驼峰属性 userName生成器在读取数据库字段后会自动做这个转换不需要手写。第二每个字段都带 ApiModelProperty 注解这为后面 Swagger 文档自动生成铺好了路——接口文档里的字段说明不需要再单独维护。用 MyBatis-Plus 这套注解实体可以省掉大量手写的 XML 映射配置。需要留意的是数据库字段类型和 Java 类型之间的映射bigint 对应 Longvarchar 对应 Stringdatetime 生成的是 LocalDateTime如果项目里还在用 java.util.Date生成后批量替换一下类型即可。3.2 mapper 与 repository数据访问入口的分工public interface UserMapper extends BaseMapperUserEntity { }mapper 接口继承了 BaseMapper 之后插入、按 ID 删除、按 ID 查、按条件统计这些方法全都有了。这是 MyBatis-Plus 省代码的核心——单表操作不需要在 XML 里写 SQL。生成出来的 mapper.xml 主要起两个作用一是给复杂查询预留扩展位二是定义 ResultMap 和基础查询列日常 CRUD 几乎用不到但写多表关联时不用回头补映射。repository 这层是这个生成器比较特别的地方它不是 MyBatis-Plus 框架强制要求的更像是数据访问门面。效果是把 mapper 和 service 隔开方便在调度层统一加缓存、加事务注解。常见写法是Repository public interface UserRepository extends UserMapper { }继承 UserMapper既拿到 BaseMapper 的全部能力又在语义上独立出来。后面 service 层依赖 UserRepository 而非 UserMapper想替换或者加切面的时候改动面就只有 repository 这一条线。如果你的项目没有分层习惯直接删掉 repository 也不会影响编译。3.3 controller 与 service接口到数据库的完整链路RestController RequestMapping(/user) Api(tags 用户管理) public class UserController { Autowired private UserService userService; ApiOperation(分页查询) GetMapping(/page) public Object page(RequestParam Integer pageNo, RequestParam Integer pageSize) { return userService.page(pageNo, pageSize); } ApiOperation(新增用户) PostMapping(/add) public Object add(RequestBody UserEntity entity) { return userService.add(entity); } }controller 里每个方法都带 ApiOperation路径按表名自动生成入参直接绑定实体。生成器在返回类型上通常给出的是通用结构落到项目里按你现有的 Result 或 R 包装类改一下签名即可这个工作量很小。service 接口和实现类则把业务方法聚在一起分页、新增、修改、删除、详情五个方法各占一个文件位置。整套串起来就是controller 收参 → service 写业务 → repository/mapper 落库。看到这里你就明白了生成器不是在造轮子而是把表和 Java 类之间的胶水代码批量糊好了。你要做的是在 service 实现类里补业务校验、补事务边界把生成器的“通用”改成你项目的“专用”。4. 完整实战用 test.sql 从建表走到项目落地前面拆完了文件职责这一章把整个流程走一遍。资源包自带 test.sql这就是用来验证生成器是否跑通的试金石。4.1 先建表test.sql 导入到本地数据库用 MySQL 命令行演示导入mysql -uroot -p123456 test.sql导入后确认表是否建成SHOW TABLES;看到测试表出现在列表里再执行 DESC 看一眼结构和主键。这一遍确认特别值得做后面生成器连库读表结构时表名、主键、字段类型的问题会先在这里暴露一次总比生成完代码发现主键类型不对要省事。4.2 改配置生成outdir 指到你的工程目录接下来把 mybatisplus.json 里的 outdir 指到一个临时目录或者直接指向工程源码目录。常见做法是先指到独立目录生成完检查文件没问题再复制进工程避免生成失败时污染现有源码。{ outdir: D:/workspace/my-project/src/main/java, jdbcUrl: jdbc:mysql://127.0.0.1:3306/demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai, jdbcUser: root, jdbcPwd: 123456, packageName: com.company.order, tableList: user }outdir 直接指到 src/main/java生成器会自动按包名展开目录packageName 一定要改成工程的实际包名 com.company.order。双击 start.bat窗口里能看到连接的库名、开始生成的表名以及每个文件的输出路径。生成完到 outdir 下检查目录结构应该和工程包名对应src/main/java/com/company/order ├── controller/UserController.java ├── service/UserService.java ├── service/impl/UserServiceImpl.java ├── repository/UserRepository.java ├── mapper/UserMapper.java ├── mapper/UserMapper.xml └── entity/UserEntity.java注意如果工程里已经有同名文件备份好再生成同名文件会被覆盖。4.3 复制进项目改掉这几处就能编译生成完六类文件复制到工程目录后还差最后几步。第一步确认 Result、分页对象这些公共类在工程里存在没有就按项目现有返回格式调整 controller 的方法签名。第二步在 service 实现类上补上 Service 和事务注解生成器倾向于只出骨架业务注解这类涉及项目约定的东西通常要自己补Service public class UserServiceImpl extends ServiceImplUserRepository, UserEntity implements UserService { }Service 让 Spring 能扫描到这个实现类ServiceImplUserRepository, UserEntity 是 MyBatis-Plus 提供的快速实现方式IService 里自带的 save、removeById、page 等方法直接可用。第三步检查 swagger 依赖是否已在 pom 里Api、ApiOperation 注解类缺失会导致编译失败dependency groupIdio.springfox/groupId artifactIdspringfox-swagger2/artifactId version2.9.2/version /dependency把项目启动起来访问 Swagger 页面能看到生成接口的路径描述和字段说明说明整条链路已经通了。从建表到接口文档出现差不多十分钟比手写快出一个量级。5. 代码生成器避坑指南五个翻车点与排查方法工具虽然简单跑起来之后的坑一点都不少。下面五条全是实操中真实遇到的按启动阶段和生成结果阶段分开说。5.1 启动阶段的三个翻车点现象一双击 start.bat 窗口一闪而过什么日志都没留下。原因多半是 java 环境变量没配好或者 jar 路径带中文或空格。解决先在命令行手动执行 java -version 确认 JDK 1.8 及以上再检查 start.bat 里的 jar 路径改成绝对路径并确保目录无中文无空格。现象二控制台报 Access denied for user。原因jdbc 账号权限不足生成器要读 information_schema 里的表结构普通业务账号经常没有这个权限。解决给账号授权或者首次复现时直接用 root 跑一次生成。不建议长期用 root但快速验证时用 root 没问题。现象三报 Unknown database。原因jdbcUrl 里的库名和 test.sql 实际导入的库名不一致。解决SHOW DATABASES 确认库名回填到 jdbcUrl 中。这一步看着低级实际最常见因为 test.sql 里的建表语句可能带了 USE 关键字直接导入到默认库和你配置的库对不上。5.2 生成结果的两个翻车点现象四生成的实体字段全乱下划线没转驼峰注释丢了一半。原因jdbcUrl 缺少 characterEncoding 参数或者连接串里没开 useInformationSchema。解决在 jdbcUrl 末尾补上 characterEncodingutf8重新生成。这套代码生成器的字段解析依赖数据库驱动读表注释连接串有问题会直接体现在注释丢失、字段错位这些症状上。这个坑最隐蔽生成的代码看起来完整但 Swagger 文档里全是空注释排查方向一直以为是生成器坏了最后发现是数据库连接串的锅。现象五tableList 写了多个表但只生成了一张。原因分隔符用了中文逗号或者行尾多了空格和换行。解决改用英文逗号并检查 tableList 的值不要带多余空白。配置文件的坑就属于这种玄学——肉眼看起来一样解析就差一个字符。所以我现在跑完生成的第一件事就是抽查一张表的 entity 注释是否完整、字段顺序是否符合预期确认没问题再批量复制进项目。别等到编译报错再倒回去查 json那会浪费一倍时间。6. 更进一步改模板与差异化验证生成器跑通只是第一步真正让工具长在自己手上的是改模板。jar 包里常见的模板格式是 Velocity 的 .vm 文件模板里混着 Java 代码和占位符变量。比如想给所有 controller 统一加一个 Validated 校验注解直接改 vm 模板再重新执行 jar 生成所有表都会带出来。这个能力特别适合团队有统一规范的时候——把规范烧进模板比写文档再让人遵守靠谱得多。改模板的操作不复杂用压缩工具打开 jar找到 resources 目录下的模板文件替换后重新打包或者放在外部目录覆盖加载。唯一要注意的是模板里的变量语法不要改错比如字段遍历的 foreach 结构一旦写错生成出来的 Java 文件直接编译不过。改之前先备份原模板是小成本换大安稳的习惯。验证方法我说一个习惯每次生成新一批代码时先拿一张表和上一版做 diff。用 IDEA 的 Compare 或 git diff 看实体和 controller 的变化判断是预期的规范变更还是意外改动。如果只是调整了字段位置说明模板改对了如果出现方法被删、注解丢失回头查模板里的遍历逻辑。最后提醒一点生成器适合处理八成的常规 CRUD剩下两成的业务个性化逻辑不要硬往生成器里塞——比如带复杂状态机的订单流程、多表聚合查询这些还是手写更清晰。工具的价值是帮你省掉重复劳动的时间不是替代思考。从那以后我每次拿到新的表结构都强制走一遍建测试表、生成、抽查 entity 注释、编译验证的流程项目里的同事照着这个步骤做再没返工过。希望这篇笔记能让你少踩几个坑顺利把工具用起来。本文还有配套的精品资源点击获取