做了多年的Spring Boot和Spring Cloud项目之后我对“代码生成器”这个词的感情其实有点复杂。一方面微服务架构下的重复劳动实在太多Controller、Service、Mapper、DTO、配置类每天像流水线一样写着结构高度雷同的代码另一方面市面上不少代码生成器生成的代码质量堪忧要么是堆了一堆用不上的模板方法要么是生成完还需要手动改一大半反而比手写还累。所以当有人问“代码生成器到底是不是开发利器”我的回答通常是关键看你怎么选、怎么用、怎么改。这篇就围绕代码生成器在Spring Boot和Spring Cloud场景下的实际落地把我踩过的坑、总结出来的选型标准以及一套真正能跑通完整开发流程的生成器使用思路一次说清楚。1. 最开始我也看不上代码生成器直到被重复劳动逼疯1.1 微服务架构下的“伪创造性劳动”先说一个真实场景。去年我们团队做了一个企业级的业务中台拆了11个Spring Boot服务再加上Spring Cloud Gateway、Nacos、Sentinel这些基础设施一次性要交付的REST接口超过200个。你掰着手指算一下就明白每个接口背后几乎都有同一套流程实体类、Mapper接口、Mapper XML、Service接口、ServiceImpl实现、Controller、DTO转换、异常处理运气好还要再加一套字段校验和分页查询。这些代码重不重要重要。但有没有创造性坦白讲大部分没有。它们只是把表结构翻译成Java代码再把Java代码包装成HTTP接口而已。等我写到第四个服务的用户模块时看着手底下一模一样的分页逻辑我第一次认真考虑引入代码生成器。一个很扎心的事实是微服务之所以让人觉得开发量大不是因为业务本身复杂而是因为同样的代码骨架被复制了几十上百份。每份骨架单独写不算多但乘以服务数量就变成了巨大的时间黑洞。而代码生成器本质上是把“复制粘贴”变成了“参数化生产”。1.2 代码生成器真正解决的四个问题在深入研究之前我先把代码生成器解决的问题列了一个清单这样后面做技术选型时才有依据消灭重复代码CRUD接口、实体映射、分页查询这类结构性代码不再需要人肉编写。保持规范统一团队里有人习惯返回Result对象有人直接返回实体有人参数校验写在Controller层有人写在Service层生成器可以从源头统一这一切。加快项目启动速度新服务从Nacos注册到Gateway路由再到基础CRUD全套用生成器一次性拉起来比手写快得多。降低新人上手门槛新人不需要从一开始就搞清楚Spring Data JPA和MyBatis-Plus的每一种写法先看生成出来的代码理解框架的调用关系再逐步深入。当然这四项好处是有代价的。代价就是你得先花时间和精力把生成器配置好、模板调好。很多团队卡在“配置阶段”就放弃了然后继续人肉CRUD。我后面会专门讲怎么把这笔“前期投资”控制在一个合理范围内。2. 代码生成器的四种主流形态选错了等于浪费时间很多人一提到代码生成器脑子里浮现的就是“输入表名、点击生成、下载zip包”这种在线平台。但实际在Spring Boot和Spring Cloud生态里代码生成器的形态非常多样。选错形态轻则定制成本高重则生成出来的代码根本没法融入现有工程。我先把这四种形态梳理一遍。2.1 在线脚手架平台适合启动不适合持续迭代以若依、JeecgBoot这类开源快速开发平台为代表的模式通常提供一个前端页面你输入数据库连接信息选择表它就给你生成一套可以下载的完整工程代码。这类平台的最大优势是启动快一个空项目从0到能跑可能只需要半小时。但我的亲身体验是这类平台的代码生成器更适合用来“初始化项目”而不是“持续开发”。原因很简单它生成的代码和平台自身的底层框架深度绑定如果你想换成自己团队定义的公共返回体、自定义注解、特定异常处理逻辑你得修改它的模板源码或者生成完再手动大改。一旦平台升级你的定制很容易被覆盖。2.2 本地模板引擎真正的生产力工具我把MyBatis Generator、MyBatis-Plus Generator、FastGenerator这一类的工具归入本地模板引擎形态。它们以Maven插件或代码API的形式存在执行时读取数据库表结构通过FreeMarker或者Velocity模板渲染出代码文件直接输出到你的工程目录里。这是我最推荐团队级使用的一种形态。原因有三个第一模板写在项目里跟着Git走全团队共享同一套生成规则第二模板可以随时改今天统一了分页返回结构改完模板以后所有新生成的代码自动合规第三它不依赖外部平台数据不出内网安全合规上更好把控。2.3 IDE插件适合个人效率提升不适合团队协作IDEA上的Easy Code、MyBatisCodeHelper这类插件胜在方便鼠标点几下就能在IDE里生成当前表对应的代码。我在个人项目里经常用尤其是做Demo或者写临时模块的时候效率非常高。但团队协作场景下IDE插件有两个难以忽视的问题。一个是版本碎片化每个人用的插件版本可能不一致生成的代码风格会有细微差异另一个是配置分散在各自本地新人入职装插件、配数据库连接本身就成了一道门槛。所以我的建议是它适合个人不适合作为团队主力的代码生产方式。2.4 API驱动的动态生成面向复杂系统的高级玩法在Spring Cloud体系内还有一种非常“绕”的玩法——不直接生成静态文件而是通过OpenAPI定义动态生成FeignClient、API测试代码甚至前端TS类型。具体来说用一个服务作为API网关层从OpenAPI文档动态生成整个调用链路的代码以Maven依赖形式引入各服务。这种方式的好处是Spring Cloud微服务之间调用关系极其复杂时不用为每个服务手工维护FeignClient而是从统一契约自动生成。但代价也很明显你等于为代码生成器再造了一个“元工程”这套机制的维护成本不高但绝对不低。我建议只有微服务数量超过20个且API变更频繁的团队才考虑这种玩法。为了帮助你快速决策我把四种形态的关键差异放在一张表里形态上手成本定制灵活性团队协作友好度适合场景在线脚手架平台低低中新项目初始化、快速原型本地模板引擎中高高企业级中后台开发的长期主力IDE插件极低中低个人项目、临时模块API驱动动态生成高极高中大规模微服务体系、接口高频变更3. 配置一个趁手的代码生成器前先想清楚四个问题代码生成器本身没有思想它的产出完全取决于你的模板和配置。所以与其到处搜“哪个代码生成器最好用”不如先回答清楚下面这四个问题答案自然会帮你筛掉大部分选项。3.1 你能容忍生成出来的代码“长得丑”吗很多团队用生成器翻车不是因为工具不好而是因为一开始没约定“丑代码”的容忍边界。比如有人接受生成器直接输出MyBatis-Plus的BaseMapper泛型方案代码很简洁有人则强制要求Mapper XML里每个SQL都手写说这样可读性强、好调优。这两种偏好会直接导向完全不同的模板写法。我个人倾向折中CRUD用生成器产出复杂查询人工手写。这样既有生成器的效率又保留了对性能敏感SQL的掌控力。团队里最好把这条原则写到开发规范里避免同一个项目里出现两套风格混乱的代码。3.2 定制点是集中在Controller日志层还是穿透到SQL层定制深度决定了生成器模板的复杂程度。举个实际例子我们团队规定所有接口必须经过一个OperateLog注解记录操作日志Controller方法参数校验统一用JSR-303注解异常统一抛出BizException由全局异常处理器转换。这些约束如果分散在生成代码的各个角落模板写起来会相当痛苦。但如果你的定制只是“类名加前缀”“包名按照服务名区分”这类浅层定制那么一个配置项就能解决完全不需要改动模板核心。我的判断标准是如果定制点超过5个就别指望纯配置完成老老实实改模板如果只是简单规则优先用工具的配置项减少模板维护面积。3.3 参数旋钮多到底好不好有些生成器号称有上百个配置项看起来无所不能真正用起来却发现百分之八十的配置你根本不知道是干什么的。而配置项少的生成器往往又无法满足实际工程的差异需求。这里我的体会很直观配置项的数量不重要重要的是它覆盖了你高频需要的那些旋钮。对我而言至少需要这些可配置项包名前缀、作者署名、是否生成Swagger注解、是否生成DTO/VO分层对象、主键策略、逻辑删除字段处理、分页插件适配。这些有了其他细枝末节都可以通过改模板解决。3.4 生成出来的代码能不能过团队的代码评审这个问题是最容易被忽略的。我见过不止一次生成器输出了一堆注释难看、命名不统一、import混乱、甚至死代码的文件然后团队负责人拿人手短不好意思说不用最后硬着头皮评审结果返工时间比手写还长。所以现在我在引入生成器前一定做一件事样例先行。拿3张有代表性的表用候选工具生成完整代码然后拉上技术委员会按平时的评审标准走一遍。能过评审的工具才允许进团队过不了的直接淘汰。这比在会上争论哪个工具“听起来不错”高效得多。4. 一套亲测有效的生成器接入流程从建表到接口跑通的完整链路当上述问题想清楚之后就可以实操了。下面这套流程是我在一个真实的中台项目里跑通过的整个过程不走弯路的话一个新模块从表结构完成到接口联调能控制在一天内。4.1 第零步表结构的设计质量决定生成代码的90%很多人把代码生成器的输入理解为“表名”其实严格说生成器的真正输入是“表结构注释约束”。如果你的表没有字段注释、没有规范的主键命名、没有统一的逻辑删除标记生成出来的代码必然是一团糟。所以在点击“生成”之前我会先花时间把表结构梳理一遍。比如每张表必须有comment级别的表和字段注释因为生成器会把它们直接变成实体类注释。主键统一命名为id类型统一为bigint或varchar(32)不要每张表一个花样。通用字段如create_time、update_time、deleted保持名称和类型完全一致这样模板里的公共处理逻辑可以复用。涉及字典的字段建议以xxx_type或xxx_status命名方便生成器识别并自动生成枚举或字典映射。我自己的经验是表结构设计占了这个流程40%的时间但它决定了剩下60%的顺利程度。你可以理解为生成器只是一个翻译器翻译质量取决于原文质量。4.2 第yi步模板分层的艺术——Controller/Services/DAO各管各的模板设计是整个环节的核心。我的做法是把它拆成独立的三组模板每组只管自己那一层的事互不掺杂DAO层模板负责实体类、Mapper接口、Mapper XML。核心在于处理好主键回填、逻辑删除、自动填充时间去这三个常见需求。Service层模板负责Service接口和实现类。这里最重要的设计是把复杂业务的“洞”留出来比如方法生成后默认抛UnsupportedOperationException提醒开发者此处需要人工补充业务逻辑。Controller层模板负责Controller和DTO/VO。重点定制出入参包装、日志注解、权限注解的自动添加。这样分层的另一个好处是某层的模板改动不会影响其他层。比如你只想在Controller层增加一个限流注解就只需要改Controller模板重新生成时选上“仅覆盖Controller”即可。4.3 第二步一定要做“可重复生成”而非“只生成一次”新手最容易犯的错误是把代码生成器当成一次性工具生成完代码之后模板就再也不动了后续所有代码都靠人肉维护。我强烈建议改变这个习惯。在Spring Boot和Spring Cloud项目里代码生成器的定位应该和编译插件一样属于工程的一部分随时可以重新执行。为了做到这一点有几个细节需要保证生成的代码有明确的区域标记比如// ---------- 自动生成区域开始 ----------和// ---------- 自动生成区域结束 ----------人工代码写在标记之外这样重新生成时不会互相覆盖。生成器配置脚本纳入Git管理任何开发人员拉下代码后都能一键执行生成命令而不是依赖某个人的IDE配置。生成前自动备份如果是全量重新生成先提交一次代码或自动打tag出现问题时能快速回滚。这套机制一旦建立起来后面加字段、加表、调整校验逻辑都会变得异常轻松。因为你不只是在生成代码你是在把“改代码”这件事本身变成了配置变更。4.4 第三步用实际案例演示一次完整的生成与微调过程为了让你更直观地理解我拿一张实际业务表来演示。假设有一个t_order表我们需要生成一套标准CRUD接口。表结构简化如下CREATE TABLE t_order ( id BIGINT NOT NULL COMMENT 主键, order_no VARCHAR(64) NOT NULL COMMENT 订单号, customer_id BIGINT NOT NULL COMMENT 客户ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单总金额, status VARCHAR(32) NOT NULL COMMENT 订单状态, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除标记, PRIMARY KEY (id) ) COMMENT订单表;在配置好数据源和包名之后执行生成命令我们得到的关键代码大致如下// 自动生成区域开始 public interface OrderService { OrderVO createOrder(OrderCreateRequest request); OrderVO getOrderById(Long id); PageResultOrderVO pageOrder(OrderPageQuery query); void updateOrder(Long id, OrderUpdateRequest request); void deleteOrder(Long id); } // 自动生成区域结束 // 人工业务逻辑添加区 OrderVO createOrder(OrderCreateRequest request) { // TODO 订单创建涉及库存校验、价格计算、优惠分摊等复杂逻辑 // 这里由人工实现不放入自动生成区域 }这里的微妙之处在于生成器生成的“外骨骼”——接口方法、入参出参、DTO映射、分页结构——全部是完整的而核心业务逻辑则通过TODO明确标识吸引开发者去补充。这种做法有几个好处编译始终能通过接口签名不会因为人工改动被破坏团队的Code Review也只需要聚焦在有TODO的人工区域。4.5 生成后的关键检查清单每次生成完代码后我并不是直接交给客户端跑联调而是快速过一遍清单大概花十分钟能避免后面大量返工Mapper XML里的SQL是否带上了tenant_id和deleted条件多租户场景必须有。实体类上的TableId和TableField注解是否与数据库主键策略一致。Controller层的路径是否采用了/api/v1/{服务名}这类规范前缀。分页对象是否实现了Serializable因为Spring Cloud场景下DTO经常跨服务序列化。application.yml里的数据源和Redis配置是否能覆盖生成代码的依赖。这些检查项看起来琐碎但它们恰恰是生成器“翻车”的高发区。尤其在做微服务多租户时如果模板里忘了拼tenant_id线上数据隔离就成了一张废纸。5. Spring Cloud场景下生成器最容易翻车的五个重灾区Spring Boot单应用里的生成器只要表和模板对得上基本不会出大问题。但到了Spring Cloud微服务环境事情就复杂得多。这里有五个地方是我反复踩坑之后总结出来的希望你能绕开。5.1 OpenFeign的版本兼容性不是生成一个Client就能跑微服务之间调用最常用的就是OpenFeign。代码生成器能帮你生成FeignClient接口但有一个坑是生成器完全帮不了你的openfeign.querydsl这类扩展库与Spring Boot版本的对应关系。举个例子Spring Boot 3.x系列的Feign依赖和Spring Cloud版本强绑定如果你在Spring Boot 3.2的工程里引入了适配2022.0.x版本的Feign扩展库启动时大概率会抛出ClassNotFoundException或者NoSuchMethodError。这类问题通常不会在生成代码时立刻暴露而是要到服务注册到Nacos、启动调用链时才会炸出来定位成本相当高。我现在的做法是在生成FeignClient之前先确认工程依赖中spring-cloud-dependencies的版本编号再以此确定Feign扩展库的版本区间。并且把这些版本信息固化到生成器的配置模板中而不是每次手动查、手动改。5.2 注册发现与配置中心的坑生成了配置不等于接入了配置如果版本对应关系是“纸面兼容”问题那么注册发现和配置中心就是“实际存活”问题。很多生成器会生成一个bootstrap.yml模板里面有Nacos地址、命名空间、group之类的占位符。新人和不了解内情的人都当它是银弹结果服务启动后直接连接超时或者拼命打印“config data not found”的警告。关键点在于配置中心的配置并不是代码层面生成一下就能生效的它还涉及Nacos服务端已有的dataId、namespace隔离环境、以及配置变更后的动态刷新链路。Spring Cloud Alibaba的配置中心如果字段名拼错比如把spring.cloud.nacos.config.shared-configs写成了sharedConfigs整个工程会在你毫无察觉的情况下丢失公共配置。针对这一点我的解决方案是生成器生成的配置文件只保留固定骨架而真正环境相关的部分例如namespace、group、shared-configs全部使用${ENV_VAR}环境变量引用由发布流水线注入。这样生成的配置文件无论谁复制到哪个环境都不会因为硬编码而泄漏信息或连错环境。5.3 远程调用链路上的参数传递Feign拦截器模板不能少Spring Cloud微服务里有个基本需求把请求头里的traceId和用户上下文透传到下游服务。这个功能通常通过Feign的RequestInterceptor实现。但如果你用代码生成器生成CRUD时完全没考虑这个需求那么生成的FeignClient只做到了“能调”做不到“有痕调”链路追踪会断成一段段孤岛。我的模板里固定会生成一个FeignRequestInterceptor它做的事情有三件从ThreadLocal或者MDC里取出traceId写入请求头。将当前登录用户信息序列化后放入请求头供下游服务解析。对于熔断、降级的场景标记出上下文是否需要向后传递避免异步线程之间互相污染。你可能会问这事跟代码生成器有什么关系关系很大。因为如果没有模板帮你把这个拦截器落实到每个新服务的初始代码里那么开发人员每新建一个服务就要记得手动补一遍这段代码。而现实是只要有一个服务忘补整个调用链路的日志就会断掉一次排查线上问题时你根本不知道肇事者是谁。5.4 服务拆分后Entity与DTO不应再有纠缠不清的依赖关系单体应用时代实体类可以被Controller直接当返回对象用。但到了Spring Cloud服务之间通过RPC通信实体类一旦被多个服务依赖它对表的强绑定就会变成负担。比如上游服务改了表字段下游服务本地类一编译全盘崩塌。所以规范的Spring Cloud工程实体和服务间传递的对象至少要做一层VO/DTO隔离。代码生成器在这一点上有一个非常容易犯的坏毛病只生成Entity和Mapper把Entity直接暴露给接口层导致服务间的数据契约变成公开的数据库Schema。你要做的是在生成器模板里把“分层对象”当成必选项Entity只在DAO层活动DTO/VO作为API层的出入参中间通过MapStruct或者手动转换器完成映射。这段话听起来很基础但在实际项目中能做到严格分层的并不多。我的观察是但凡做到严格分层的团队后面做服务升级、接口兼容、多客户端适配时都轻松很多。5.5 路由网关层的接口聚合生成器不能替你整理目录Spring Cloud Gateway是微服务流量的入口。某些号称“Spring Cloud代码生成”的工具会声称可以帮你生成网关路由配置。实际上它最多帮你生成一个路由规则的示例片段完整的路由定义还是要人工确认——因为网关路由涉及路径前缀、熔断策略、限流策略、鉴权过滤器的嵌套关系这些都是生成器无法凭空推断的。我建议网关路由配置永远走人工维护不要进生成器模板。生成器的合理边界在“服务内部代码”网关层是“服务间治理”两者的关注点完全不同。强行用生成器生成路由规则会让本来清晰的网关配置变成一团无法预测的YAML。而且网关层的路由一旦出错影响面是全局的调试起来也比服务内部代码麻烦得多。宁可花人力在这个关键位置多检查几遍也不要指望一道生成命令解决所有治理问题。6. 当Spring Cloud Alibaba遇上非Java应用生成器解决不了的那部分标题里出现了Spring Cloud Alibaba有个热词“python应用融入spring cloud alibaba微服务体系”这里值得展开聊一下。很多人以为Spring Cloud Alibaba是Java的专属生态其实并不完全是这样。当你有一个Python服务想融入Nacos注册发现、配置中心和链路追踪体系的时候你会发现代码生成器的“Java思维”完全没有用武之地。这一节我聊聊怎么做非Java接入以及为什么这种场景不该硬套生成器。6.1 Python应用接入Nacos注册中心协议对齐才是关键Python服务要接入Spring Cloud Alibaba体系第一件要做的事不是写代码而是理解Nacos的OpenAPI。Nacos本身提供了HTTP接口所以任何语言只要能发起HTTP请求就能完成服务注册、心跳续约和服务发现。具体来说Python服务启动时需要向Nacos的/nacos/v1/ns/instance接口发送POST请求携带ip、port、serviceName、namespaceId、groupName、metadata等参数并且要按照类似的HTTP接口实现心跳。用代码生成器帮不上什么忙因为这不是“生成模板”能覆盖的领域而是“服务生命周期管理”的设计问题。这里有个最容易出错的点服务名的规范。Spring Cloud Alibaba的服务名约定通常是服务名-环境-标签的形式如果Python服务注册的服务名和Java服务不一致或者大小写风格不统一在Nacos控制台里会看到两套命名体系治理的时候极其混乱。6.2 Python应用接入配置中心不止是“读配置”那么简单Nacos配置中心跟Spring Cloud Alibaba的深度集成体现在一个核心机制上配置变更后的自动刷新。Java端通过RefreshScope注解在配置变更时能自动重建Bean实现动态刷新。而Python应用没有这套机制你需要自己实现配置拉取、比对、回调甚至热更新的逻辑。我的建议是给Python应用封装一个轻量级的配置客户端它负责三件事启动时拉取全量配置建立本地缓存。定时或长轮询比较配置中心的版本号发现变化后拉取增量。触发配置变更回调让业务模块自行决定是否重建连接池、是否刷新路由表。这个逻辑和代码生成器完全无关但它恰恰是“微服务体系”里最有价值的部分。很多团队把Python服务硬塞进Spring Cloud体系之后只做了注册发现配置中心完全没用起来一个配置要重启服务才能生效。这种半吊子接入说好听点是渐进式说实话是埋雷。6.3 Python应用融入链路追踪别指望JSCH或Sleuth的自动埋点Spring Cloud Alibaba的链路追踪体系一般通过Sleuth Zipkin/OpenTelemetry实现Java应用可以靠agent或者注解自动埋点。Python生态里虽然也有OpenTelemetry的Python SDK但并不意味着你引入依赖后就自动拥有了全链路能力。你需要手工在关键入口加上SpanHTTP请求进入时创建根Span调用数据库时创建子Span调用外部HTTP服务时通过requests库的钩子把traceId注入到Header。这个过程没有模板可言因为每个Python服务的框架不同FastAPI、Flask、Django的中间件钩子写法都不一样。6.4 为什么这类“体系接入”不应该用代码生成器回到正题为什么Python融入Spring Cloud Alibaba这类场景代码生成器完全帮不上忙原因是代码生成器的本质是“结构重复”而跨语言服务接入的本质是“协议适配”。结构重复的任务适合用模板批量生产协议适配的任务则必须理解协议细节针对特定场景手工编码。如果你试图把协议适配逻辑也塞进代码生成器你会得到一个巨大的、不可维护的模板灵活性接近零。所以我的建议一直是代码生成器聚焦在Java服务的内部标准结构跨语言接入交给专门的接入SDK或中间件团队去封装。反过来想如果一个团队能把Python、Go等异质服务在Spring Cloud体系里的接入规范沉淀成一套完善的SDK那才是比任何代码生成器都更有价值的“资产”。7. 代码生成器真正打动我的一个细节版本控制与自动化流水线的融合聊了这么多最后再分享一个让我彻底改变对代码生成器态度的细节也顺便聊聊它和DevOps流水线怎么结合。Spring Cloud微服务工程迭代速度快依赖升级频繁。比如Spring Boot从2.x升级到3.x时javax包要换成jakarta包Spring Security的配置方式也发生了巨变。这种升级如果靠团队通知、靠人肉修改每升级一次都要经历漫长的痛苦期。但如果你把代码生成器模板纳入版本控制升级工作就变成了一件很酷的事你只需要更新模板把javax改成jakarta把旧版Security统一改写成Spring Security 6的SecurityFilterChain写法然后对所有服务统一执行一次重新生成。那些“只生成一次、从此人肉维护”的代码此时仍然只能手动改而你所有沿用模板的代码都会自动跟上新版本的技术栈。这两年我在实际工作里最受用的一个操作就是把代码生成器接入了公司的GitLab CI流程中。每当有建表脚本合并到主分支流水线会自动触发代码生成任务把生成的代码作为MR提交代码评审。这意味着团队里任何一个人都不需要为“忘跑生成器”而担心因为这个动作本身已经被自动化吞掉了。这个思路可以延伸得很远。比如你可以在模板里同时生成单元测试骨架在CI阶段自动校验生成的代码是否编译通过也可以在生成器里内置依赖版本检查逻辑一旦发现openfeign.querydsl与当前Spring Boot版本不兼容生成器给出明确的报错信息。到这里代码生成器就不再是一个“提高手速的小工具”而成了连接数据库设计、代码工程、依赖治理和流水线规范的基础设施。回头看我当初对代码生成器的偏见其实不是工具的问题而是我把它看得太小了。真正好用的代码生成器未必功能最多但它一定嵌在了整个工程体系里让所有重复工作变得可预期、可重复、可升级。这也是我认为它配得上“Spring Boot、Spring Cloud开发利器”这个称号的根本原因。如果你所在的团队还在靠人肉复制Controller和Mapper真心建议从一个小模块开始把模板跑起来试试你会很快感受到这套玩法带来的变化。