写Java后端这几年最让我烦躁的不是业务逻辑有多复杂而是每接一个新模块都要重复一套一模一样的体力活建表、写实体类、写Mapper接口、写XML映射文件、写Service、写Controller。这些代码毫无技术含量但少了哪一环都不行纯纯消耗耐心。MyBatis-Plus 的代码生成器就是冲着这个问题来的它看一眼数据库表结构把实体、Mapper、Service、Controller 一次性全部生成完你只需要在结果上做业务扩展就行。Old 版本的 AutoGenerator 写法繁琐、配置分散尤其是 3.5.1 之前那种各种 setter 满天飞的老写法用起来相当别扭。新版 FastAutoGenerator 则把配置整个收拢成链式调用整个生成器核心逻辑一眼就能读完。这篇文章我就把新版代码生成器的配置项、完整实操、踩坑记录一次性拆透Java 后端无论是刚接触 MyBatis-Plus 的初学者还是准备把老版本生成器迁移过来的老手都可以直接照着抄。1. 新版代码生成器到底“新”在哪1.1 老版本的使用痛点我在 3.5.1 版本之前用 AutoGenerator 的体验相当分裂。功能上它确实能干不少事生产环境帮我生成过好几个项目的骨架代码效率比手写高得多。但使用体验上却一直没跟上时代你要先 new 一个 AutoGenerator然后分别 setDataSource、setGlobalConfig、setPackageInfo、setStrategy一堆对象之间还要互相传引用每个 Config 内部又是一堆 setter 链。配置项稍微多一点整个启动类就变得又长又难读。记得有一次新同事接手一个老项目的生成器配置光是把启动逻辑梳理明白就花了大半天。另一个让人头疼的问题是版本兼容。mybatis-plus-generator 和 mybatis-plus 主版本的对应关系在早期版本里不够清晰依赖冲突、模板引擎加载失败的情况时有发生。当时我印象特别深的一个场景是项目从 Spring Boot 1.x 升到 2.x连带 mybatis-plus 升到 3.4.x结果生成器直接起不来了排查了半天才发现是 generator 版本没跟着升velocity 模板引擎在解析时出了问题。类似这种问题在老版本里排查成本特别高。还有一个团队协作层面的痛点老版本生成出来的代码风格默认值太多Controller 有的带 RestController、有的是 Controller实体类的注释格式也是五花八门。只要团队里两个人各自跑过生成器代码风格基本上就对不齐每次 merge 都要花额外时间统一风格。这一点在团队规模上来之后尤其致命。1.2 新版 API 的核心变化3.5.1 版本开始官方推出了 FastAutoGenerator这是一次彻底的重构。它把原来分散的 DataSourceConfig、GlobalConfig、PackageConfig、StrategyConfig 全部收拢到一条链式调用里整个生成器的核心行为通过几个 builder 方法就能完整表达。我贴一段最基础的用法你们感受一下这种写法的直观程度FastAutoGenerator.create(url, username, password) .globalConfig(builder - builder.author(yourname).outputDir(/src/main/java)) .packageConfig(builder - builder.parent(com.example.demo)) .strategyConfig(builder - builder.addInclude(t_user)) .execute();这种链式写法对比老版的好处是显而易见的。配置项按阶段分组全局配置、包配置、策略配置各自成块你顺着链从开头读到结尾这个生成器会干什么基本心里有数。团队做代码评审的时候生成器配置的改动也可以通过 git diff 很直观地看出来到底是改了输出目录、调整了包名还是新增了要生成的表。除了 API 风格的变化新版在自动化和扩展性上也有明显改进。最典型的例子是数据库类型识别老版本需要手动指定 DbType新版 FastAutoGenerator 内部会通过 JDBC URL 自动判断默认行为对绝大多数项目都够用。生成器本身也从 mybatis-plus 里解耦出来成为一个独立的组件可以在任意项目里单独引入甚至可以封装成 Maven 插件或者内部 Web 服务团队里把这个能力平台化也很方便我见过不少团队就是这么干的。注意如果你的项目里还保留着老版本 AutoGenerator 的启动类升级到新版后旧的写法基本不可用需要把启动逻辑整体迁移到 FastAutoGenerator 的链式写法上。迁移本身不复杂但建议留出专门的测试时间跑一遍对比生成的代码差异尤其是自定义模板的路径和参数名称变化。2. 依赖引入与环境准备2.1 版本选型与匹配关系先说版本选择这是很多新手一上来就踩坑的地方。代码生成器并不在 mybatis-plus 的主包里需要单独引入而且 generator 的版本和 mybatis-plus 主版本虽然有关联但不会自动传递依赖。我的建议是 generator 版本和项目里的 mybatis-plus 主版本保持在同一个大版本范围内比如主版本用的 3.5.9generator 也用 3.5.x 的最新版本。我整理了一份常用的版本搭配参考按项目所处阶段和 JDK 环境做了区分。下面这张表是基于我在多个项目里的实际使用情况整理的不敢说覆盖所有组合但至少避免你们在选型上走弯路项目场景MyBatis-Plus 主版本Generator 版本JDK 环境Spring Boot 环境传统企业项目3.4.x3.4.xJDK 8Spring Boot 2.x常规新项目3.5.13.5.1JDK 8~17Spring Boot 2.x较新或云原生项目3.5.33.5.3JDK 8~21Spring Boot 2.x/3.x版本匹配这块有一个需要特别留意的变化如果你用的是 Spring Boot 3.xmybatis-plus 的 starter 不再叫mybatis-plus-boot-starter而是mybatis-plus-spring-boot3-starter。很多从 Boot 2 升到 Boot 3 的项目代码生成器本身没什么问题但项目启动时就因为 starter 引用错误直接起不来这个坑我后面会专门展开。2.2 依赖坐标与模板引擎选择代码生成器本体和一个模板引擎依赖是需要同时引入的缺一不可。我习惯用 freemarker依赖坐标如下dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-generator/artifactId version3.5.9/version /dependency dependency groupIdorg.freemarker/groupId artifactIdfreemarker/artifactId version2.3.32/version /dependency这里要重点说一下模板引擎的选择逻辑。官方默认带的是 velocity但从这些年的社区反馈和实际表现来看velocity 的维护节奏明显放缓在 JDK 17 环境里偶尔会冒出一些反射相关的告警甚至异常。freemarker 这边活跃度高、资料多模板语法对写 Java 的人也更友好所以我在新项目里基本都指定 freemarker。当然你完全可以用 velocity 或者 beetl这属于个人选择没有绝对的高下之分但从“遇到问题好搜、好查、好解决”这个角度新手我建议直接 freemarker。另一个容易忽略的细节是只引 generator 不引模板引擎启动时会直接报找不到模板引擎的错误。这不是配置问题就是依赖缺失引入对应模板引擎后立刻就能跑通。顺带说一下如果你把生成器封装的代码放到 Maven 的环境里跑记得确认模板引擎依赖是 compile 级别而不是 provided否则运行时会抛 ClassNotFoundException。3. 核心配置逐项拆解3.1 数据源配置基础中的基础数据源配置是整个生成器里最不能出错的一环因为后面的表结构读取全靠它。我常用的写法是这样的FastAutoGenerator.create( jdbc:mysql://localhost:3306/mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai, root, root123456 )MySQL 的 URL 里serverTimezoneAsia/Shanghai必须要加这个老生常谈但总是有人漏。MySQL 8 以上的驱动对时区要求很严格不加这个参数会直接报The server time zone value ... is unrecognized。还有一个安全习惯生成器的数据库账号建议用最小权限账号只要具备读表结构、读表注释、读字段注释的权限就够了。代码生成器只做读取操作不需要 drop/create 权限用 root 账号跑生成器属于典型的安全隐患万一代码里不小心写了别的操作后果很难预料。数据源配置这块还有一个隐藏的扩展点——类型转换。MyBatis-Plus 内置的默认类型转换在一些边界情况下跟你的预期不一致比较典型的是 MySQL 的tinyint和bit类型。很多表设计里用tinyint(1)表示状态默认转换逻辑会把它当成 Boolean 类型但如果你在业务代码里只想用 Integer 来接收就需要自定义类型转换器.dataSourceConfig(builder - builder.typeConvert(new MySqlTypeConvert() { Override public DataType processTypeConvert(GlobalConfig globalConfig, String fieldType) { if (tinyint.equals(fieldType.toLowerCase())) { return DbColumnType.INTEGER; } return super.processTypeConvert(globalConfig, fieldType); } }))这样生成的实体里所有tinyint字段就是 Integer 而不是 Boolean业务代码里的判断逻辑就不用继续在 Integer 和 Boolean 之间来回转换了。3.2 全局配置输出目录与作者信息全局配置控制的是生成结果的整体风格。我示范一下常用配置并说明每一项的作用.globalConfig(builder - builder .outputDir(System.getProperty(user.dir) /src/main/java) .author(chen) .enableSwagger() .dateType(DateType.TIME_PACK) .commentDate(yyyy-MM-dd) .disableOpenDir() )outputDir生成代码的根输出目录。单模块项目直接写到src/main/java下多模块项目需要根据模块路径调整这个是出现频率最高的配置项。author生成的类注释里author的作者名按团队规范配置就好。enableSwagger()开启之后实体类和 Controller 的方法上会带ApiModel、ApiOperation等 Swagger 注解前提是项目里已经引入了 swagger 依赖。如果你用的是 SpringDoc 那套这个选项就不需要开了。dateType(DateType.TIME_PACK)日期类型使用java.time包下的类型也就是LocalDateTime、LocalDate这些而不是老的java.util.Date。新项目强烈建议开这个老项目要反序列化兼容的话可以再权衡。commentDate(yyyy-MM-dd)类注释里的日期格式纯团队审美问题但固定格式能减少 git diff 的噪音。disableOpenDir()关掉生成完成后自动打开输出文件夹的行为。这个选项在本地开发时不重要但如果生成器在构建服务器上跑自动弹文件夹不仅没用还可能引发权限问题建议直接关掉。3.3 包配置分包设计与团队协作包配置决定了生成的代码落在哪个包路径下。结合多模块项目和微服务场景分享一下我的实践.packageConfig(builder - builder .parent(com.example.mall) .moduleName(order) .entity(entity) .service(service) .serviceImpl(service.impl) .mapper(mapper) .controller(controller) .xml(mapper.xml) .pathInfo(Collections.singletonMap(OutputFile.xml, System.getProperty(user.dir) /src/main/resources/mapper)) )parent配置的是父包名moduleName是模块名。为什么需要 moduleName因为在一个中大型系统里数据库表往往按业务域拆成多个模块比如商城项目里既有订单域、也有商品域、用户域每个域下都会有名为OrderService、ProductService、UserService的类。如果生成时不加模块名所有 Service 全堆在同一个包下类名冲突是迟早的事。加上 moduleName 之后生成的包路径就是com.example.mall.order.service、com.example.mall.product.service各模块之间清爽隔离。pathInfo这个配置容易被忽略但它解决的是 XML 文件输出路径问题。默认情况下Mapper 的 XML 文件会生成到src/main/java对应包路径下但 Maven 项目规范要求 XML 放在src/main/resources下。我见过不少团队生成的 XML 全部跑到了 java 目录里编译时资源文件没有一起打包运行时各种Invalid bound statement报错。这里的处理方式就是用pathInfo把 XML 的输出目录单独指到src/main/resources/mapper一劳永逸。3.4 策略配置表与字段的精细控制策略配置是整个生成器里最能提现功力的部分也是玩得出花样的地方。先看我实际项目里的配置.strategyConfig(builder - builder .addInclude(t_order, t_order_item, t_user) .addTablePrefix(t_) .entityBuilder() .enableLombok() .enableTableFieldAnnotation() .logicDeleteFieldName(deleted) .versionFieldName(version) .controllerBuilder() .enableRestStyle() .mapperBuilder() .enableBaseResultMap() .enableBaseColumnList() )逐项解释一下。addInclude指定生成哪些表这是防止生成器“过度生产”的关键。默认情况下不写这个生成器会扫数据库里所有表包括各种系统表、中间表、日志表。我见过一个新手项目跑完生成器之后发现 classes 目录底下多出了几百个类就是因为没限制范围。正确的做法是只在addInclude里列出这轮要生成的表一次别贪多。addTablePrefix(t_)是表前缀过滤规则t_order表生成的实体叫Order不会带T前缀。业务表如果没有统一前缀这里就不用配但强烈建议建表时给核心业务表加统一前缀这是表规范设计的一部分生成器会受益很多。接下来是entityBuilder()下的几个选项enableLombok()生成的实体类用Data注解避免生成大量 getter/setter。现在的新项目基本都上 Lombok没理由不用。enableTableFieldAnnotation()每个字段上带TableField注解明确指定字段到数据库列的映射关系。开这个可以让实体对字段名变更保持一定弹性排查问题时也更直观。logicDeleteFieldName(deleted)指定逻辑删除字段生成实体时会在该字段上加TableLogic。MyBatis-Plus 拿到这个注解执行 delete 操作时自动变成 update 语句。这是所有生产项目都该做的配置否则物理删数据的事故早晚会发生。versionFieldName(version)乐观锁字段加了Version注解后配合乐观锁插件实现并发控制。然后是controllerBuilder()的enableRestStyle()生成RestController而不是Controller前后端分离项目没有理由不用 Rest 风格。最后是mapperBuilder()的enableBaseResultMap()和enableBaseColumnList()。这两个不开的话生成的 Mapper.xml 几乎是空的开起来之后XML 里会预先生成基础 ResultMap 和基础的列集合sql。后面你写复杂多表关联查询时直接 extend 这个基础 ResultMap再动态拼接额外字段比从零手写一遍安全高效得多。3.5 模板引擎与自定义模板模板引擎的指定非常简单.templateEngine(new FreemarkerTemplateEngine())真正值得花时间的是自定义模板。为什么要自定义就拿 Controller 模板来说默认生成出来的 Controller 就是一个空壳只有简单的 CRUD 接口返回的是实体本身。如果团队里统一要求 Controller 继承某个 BaseController或者所有接口返回值必须是统一包装类RT默认模板生成的代码完全不符合规范你仍然要手动改一遍生成器的价值就大打折扣。我的实践是把生成器内置的模板文件拷出来放到项目src/main/resources/templates下按团队规范修改后再通过templateConfig指定自定义模板位置。比如 Controller 模板修改的核心思路是类注解从RestController保留加上统一的RequestMapping路径风格所有接口方法的返回值改成RT包装类型方法上自动加日志注解或统一异常处理的标记。这里没有标准答案完全取决于团队技术规范。我想强调的思路是代码生成器是团队代码规范的“固化器”你花一两个小时定制一套模板之后每天的项目代码都会自动遵从这套规范投入产出比非常可观。4. 完整实操从零跑通一次代码生成4.1 编写生成器主类把前面讲的所有配置串起来一个可运行的生成器主类长这样。我建议把这类代码放到项目的tools或generator包下不要放在业务代码包路径里避免误扫描和版本管理噪音public class CodeGenerator { public static void main(String[] args) { FastAutoGenerator.create( jdbc:mysql://localhost:3306/mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai, root, root123456) .dataSourceConfig(builder - builder.typeConvert(new MySqlTypeConvert() { Override public DataType processTypeConvert(GlobalConfig globalConfig, String fieldType) { if (tinyint.equals(fieldType.toLowerCase())) { return DbColumnType.INTEGER; } return super.processTypeConvert(globalConfig, fieldType); } })) .globalConfig(builder - builder .outputDir(System.getProperty(user.dir) /src/main/java) .author(chen) .enableSwagger() .dateType(DateType.TIME_PACK) .commentDate(yyyy-MM-dd) .disableOpenDir()) .packageConfig(builder - builder .parent(com.example.mall) .moduleName(order) .entity(entity) .service(service) .serviceImpl(service.impl) .mapper(mapper) .controller(controller) .xml(mapper.xml) .pathInfo(Collections.singletonMap(OutputFile.xml, System.getProperty(user.dir) /src/main/resources/mapper))) .strategyConfig(builder - builder .addInclude(t_order, t_order_item) .addTablePrefix(t_) .entityBuilder() .enableLombok() .enableTableFieldAnnotation() .logicDeleteFieldName(deleted) .versionFieldName(version) .controllerBuilder() .enableRestStyle() .mapperBuilder() .enableBaseResultMap() .enableBaseColumnList()) .templateEngine(new FreemarkerTemplateEngine()) .execute(); } }配置项里的数据源账号记得换成自己本地环境的。整个执行过程会打印每一步的日志生成完成后可以看到类似Generator create entity [Order] success!的输出说明实体类已经成功写入对应目录。4.2 生成的代码结构解析跑完一遍之后生成的目录结构是这样的com/example/mall/order/ ├── controller/ │ └── OrderController.java ├── entity/ │ └── Order.java ├── mapper/ │ └── OrderMapper.java ├── mapper.xml/ │ └── OrderMapper.xml └── service/ ├── OrderService.java └── impl/ └── OrderServiceImpl.java拿实体类举例生成出来的代码长这样每个字段的数据库映射、注解、逻辑删除和乐观锁标注都很清晰Data TableName(t_order) public class Order { TableId(value id, type IdType.AUTO) private Long id; TableField(order_no) private String orderNo; TableField(amount) private BigDecimal amount; TableLogic private Integer deleted; Version private Integer version; }这里每个注解都有它的实际意义。TableName把实体类与数据库表 t_order 关联起来TableId指明主键字段和自增策略TableField明确字段到列的映射关系TableLogic让 delete 自动变 updateVersion让更新操作自动带乐观锁校验。这些注解加完之后MyBatis-Plus 在运行时就能准确知道如何做对象关系映射不需要你再额外写任何配置。再看 Mapper 接口生成出来的代码简单得让人“怀疑人生”public interface OrderMapper extends BaseMapperOrder { }但这个“简单”恰恰是 MyBatis-Plus 整个框架的精华继承BaseMapperT之后单表增删改查方法全部内置比如selectById、insert、deleteById、updateById、selectList、selectPage等等。你不需要在 XML 里写任何单表 CRUD 的 SQL。同理Service 接口继承IServiceOrder实现类继承ServiceImplOrderMapper, Order批量操作能力也跟着一起继承下来了。按照我实际生成后的经验最理想的流程是先用代码生成器把骨架全部拉出来然后只在 Controller 层补充参数校验和业务编排在 Service 层补充核心业务逻辑在 Mapper.xml 里补充复杂查询。前期的 CRUD 模板代码交给生成器就对了。4.3 与 Spring Boot 项目整合生成完代码之后接入项目其实只需要三步。第一步启动类加MapperScan指定 Mapper 接口所在的包SpringBootApplication MapperScan(com.example.mall.order.mapper) public class MallApplication { public static void main(String[] args) { SpringApplication.run(MallApplication.class, args); } }第二步配置 MyBatis-Plus 分页插件。这个在 3.5.x 版本里就是一个普通 BeanConfiguration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }如果没有这个配置分页查询selectPage会带不走分页条件直接全表返回这是个非常隐蔽的 Bug。第三步业务层直接注入 Service使用继承来的方法。这里我顺便演示一下最近很火的Db工具类它对应了网上的“无状态增删改查”说法——不用注入任何 Service直接这样用RestController RequestMapping(/order) public class OrderController { // 不需要注入任何 Service GetMapping(/{id}) public Order getById(PathVariable Long id) { return Db.getById(id, Order.class); } PostMapping(/batch) public boolean saveBatch(RequestBody ListOrder orders) { return Db.saveBatch(orders); } }Db工具类是 MyBatis-Plus 3.5.2 以后推出的轻量级 CRUD 入口适合处理零散的单表操作。我的经验是工具类适合“只需要一个方法、不值得为它新建一个 Service”的场景。但如果某个业务方法里涉及多表关联、事务边界、复杂状态流转还是老老实实写进 Service 里别为了省事把业务逻辑散落在 Controller 各处。Db是轻量武器不是万能钥匙。批量操作这里也简单提一下ServiceImpl自带saveBatch、listByIds等方法适合中小批量的常规操作。如果追求极致性能可以自定义 SQL 注入器添加insertBatchSomeColumn方法一条真正的批量 INSERT 语句插入多条记录性能比逐条插入高出不少。这个属于进阶玩法有大批量写入需求的项目值得研究。5. 常见问题与排查技巧实录5.1 生成失败排查速查表我用了这么久的生成器遇到过的典型问题集中在下面这些场景。整理成一张表方便大家遇到问题时快速定位异常现象排查方向解决办法找不到模板引擎 / TemplateException模板引擎依赖缺失引入 freemarker 或 velocity 依赖并确认是 compile 级别Unknown database / Access denied数据源 URL 或账号密码问题检查数据库连接串、账号密码、数据库名拼写Table xxx doesnt exist表名配置错误检查 addInclude 里写的表名是否和数据库一致实体类生成出来属性不全数据库账号没有读表结构权限用具备读 information_schema 权限的账号跑生成器生成的注释全是空的表和字段没有写 COMMENT先补好数据库表注释和字段注释再重新生成Mapper.xml 跑到了 java 目录没有配置 XML 输出路径用 packageConfig 的 pathInfo 指定到 resources/mapper运行时 Invalid bound statementMapper.xml 没被扫描到确认 mapper-locations 配置和实际 XML 路径一致这里的排查方向每一条都是我实际踩过或者帮同事解决过的。尤其是“实体生成不完整”这一条很多人第一反应是策略配置写错了其实大概率是数据库账号的权限不够读不到字段级元数据多给权限或者换账号就行。5.2 版本兼容性问题实录版本兼容是我在社区里看到提问频率最高的一类问题主要集中在两个场景。第一个场景是 JDK 版本升级到 17 之后老项目里的生成器突然跑不动。这个问题我在多个项目里验证过核心出在 velocity 模板引擎对高版本 JDK 的兼容性上。如果你遇到的是这种情况切换成 freemarker 基本可以解决。这也是我为什么在前面的依赖配置里坚持用 freemarker 的原因——不是 freemarker 有多么无敌而是它在高版本 JDK 环境里的稳定性确实比 velocity 好。第二个场景是 Spring Boot 3.x 项目引了老版的 mybatis-plus starter。Spring Boot 3 全面采用了 Jakarta EE 规范之前基于javax.*的那套 mybatis-plus 依赖直接失效。记住一个关键点Boot 3 项目用mybatis-plus-spring-boot3-starterBoot 2 项目用mybatis-plus-boot-starter这个别搞混了。还有一个低级但很常见的坑网上资料混杂把老版 AutoGenerator 的代码和新版 FastAutoGenerator 的代码混着抄最后编译不过。确认你项目里 import 的是com.baomidou.mybatisplus.generator.FastAutoGenerator而不是com.baomidou.mybatisplus.generator.AutoGenerator这两个是不同时代的产物API 差异极大。5.3 代码风格与团队规范的衔接生成器这个东西个人的小打小闹容易真正有难度的是一整个团队长期使用同一套生成配置。我见过太多团队里每个人本地维护一份自己的生成器配置生成的代码风格千差万别merge 到主干之后各种冲突。我的建议是生成器的主类配置要放进项目仓库里并且固定在一个公共模块下。如果团队规模再大一点可以封装成 Maven 插件的形式把数据源地址、包名、作者、表前缀等全部参数化用命令行参数去控制生成行为。这样所有人生成的代码基础骨架完全一致唯一的变量就是你传入的表名。还有一个细节代码生成器的配置要跟数据库表规范联动。比如addTablePrefix(t_)和logicDeleteFieldName(deleted)这两项隐含的假设是团队建表必须带统一前缀、必须有逻辑删除字段。如果团队里有人建表不守规范生成器生成的实体里就不带TableLogic逻辑删除的约束在那一张表上就断了。所以生成器用得好反过来也在倒逼数据库表规范的落地这是很多人没注意到的一个价值。6. 实操中的一些个人体会代码生成器用了这几年我自己最大的体会是它最值钱的不是帮你省下那几分钟敲 CRUD 的时间而是它能把你脑子里那套“命名一致、注释到位、Mapper 层规范”的标准自动固化到每一次代码生成里。这套标准落地之后团队里哪怕是刚来的实习生提交上来的代码也不会有大的风格问题。每次新项目启动时我的固定动作是先花半小时把数据库表名、字段注释修整干净然后跑一次生成器再花一小时把 Controller 模板调成团队统一风格。这些准备工作做完之后后面整个项目开发节奏会特别顺畅因为最底层的实体和 Mapper 这层已经完全规范化了团队所有人在这层之上写代码不会出现地基不一样的问题。如果你们团队还没有统一生成器配置我建议按这个顺序推进先让一个人把模板调好覆盖实体、Controller、Service 三个核心文件然后找两张有代表性的业务表跑通再拉一个小团队试点一两个迭代。等到大家都感受到“新表接入成本大幅下降”之后再全面推广阻力会小很多。这个内容后续还可以扩展成内部代码生成平台把配置、模板、数据库连接管理都收敛到一个 Web 服务里但那是另一个量级的事了先把第一步跑通再说。