做 Java 开发这些年我见过太多团队把时间耗在重复的样板代码上一个实体类要手写 getter/setter、toString、equals/hashCode一个 Mapper 接口要照着表结构一个个字段敲Controller 里的增删改查方法几乎是复制粘贴改个名字。这些活儿不难但极其消耗耐心而且手写必然出错——少个字段、类型对不上、注解漏了编译能过但运行就炸。后来我把 IDEA 里那套代码生成能力彻底摸了一遍从内置模板到自定义脚本从单文件生成到批量产出硬是把一个模块的骨架代码从半天压缩到几分钟。这篇就聊聊我是怎么在 IDEA 里做到一键生成代码的包括工具选型、模板配置、脚本编写和踩过的坑适合已经会用 IDEA 但还没系统整理过代码生成流程的开发者也适合刚接手老项目、被样板代码淹没的朋友。1. 先想清楚为什么要在 IDEA 里做代码生成1.1 样板代码到底吃掉了多少时间我先算一笔账。假设一个中等规模的业务模块有 20 张表每张表对应一个实体类、一个 Mapper 接口、一个 Service 接口和实现、一个 Controller再加上 DTO 和 VO。实体类平均 15 个字段手写 getter/setter 就是 30 个方法加上 toString、equals、hashCode一个类轻松过 200 行。20 张表就是 4000 行纯样板代码。按熟练工每分钟写 3 行算光敲这些就要 20 多个小时还不算调试字段名拼错、类型写反的时间。更麻烦的是维护成本。表结构一改实体类要同步改Mapper 的 XML 要改DTO 要改稍不留神就漏了一处等到联调时才发现字段对不上。这种错误排查起来特别费劲因为编译期不报错运行时才暴露。所以代码生成不是为了炫技而是把机械劳动交给工具把人的精力留给真正的业务逻辑。1.2 IDEA 自带能力和第三方插件的边界在哪很多人一提到代码生成就想到装插件其实 IDEA 内置的能力已经覆盖了大部分场景。我把它分成三层来看层级能力适用场景是否需要插件基础层Live Template、File Template、Postfix Completion单文件、单段代码快速补全否进阶层Database 工具窗口的 Generate POJOs、Scripted Extensions从数据库表结构生成实体否扩展层第三方代码生成插件、自定义 Groovy 脚本批量生成多文件、复杂模板视情况基础层解决的是少敲几个字进阶层解决的是从表结构到实体扩展层解决的是整套骨架批量产出。我的建议是先把手头这三层吃透再决定要不要引入外部工具。很多团队一上来就找现成的代码生成器结果模板不贴合自己的项目规范改起来比自己写还费劲。1.3 选型背后的取舍逻辑为什么我最终选择IDEA 内置 Database 工具 自定义模板 Groovy 脚本这套组合而不是直接用某个开源代码生成框架原因有三个。第一是零外部依赖。内置工具跟着 IDEA 走不需要额外引入 jar 包不需要维护生成器的版本团队新人拉下代码就能用。第二是模板可控。生成出来的代码风格、包结构、注解习惯都能按项目规范定制不会出现生成器吐出来的代码和手写代码风格打架的尴尬。第三是调试直观。脚本在 IDEA 里直接跑报错信息清晰改一行看一行比在命令行里调生成器舒服得多。当然这套方案也有短板它更适合从数据库表结构出发的生成场景如果是从接口文档生成或者从 JSON 生成就得换思路。但对大多数 CRUD 为主的业务系统来说表结构就是源头这套组合够用了。2. 基础功把 Live Template 和 File Template 用到位2.1 Live Template把高频代码片段变成缩写Live Template 是我用得最多的功能没有之一。它的逻辑很简单你定义一个缩写敲缩写按 Tab就展开成一段预设代码。IDEA 自带了不少比如psvm展开成 main 方法sout展开成System.out.println()。但真正提效的是自定义模板。我举几个自己常用的例子。日志声明我定义缩写logd展开成private static final Logger log LoggerFactory.getLogger($CLASS_NAME$.class);其中$CLASS_NAME$是变量展开时会自动取当前类名。再比如单元测试方法缩写testmTest public void test$METHOD_NAME$() { // given // when // then }配置路径在Settings Editor Live Templates新建一个 Template Group然后在组里加模板。关键是变量要设对$CLASS_NAME$这种内置变量 IDEA 能自动推断自定义变量可以设默认值或者用表达式。注意Live Template 的缩写不要和已有缩写冲突比如你定义for就会覆盖内置的循环模板。我一般给自定义模板加个前缀比如xlog、xtest避免误触。2.2 File Template新建文件时自动套骨架File Template 解决的是新建一个类文件头、包声明、类注释、基础结构自动生成的问题。路径在Settings Editor File and Code Templates。我改过Class模板加上了作者、创建时间、功能描述#if (${PACKAGE_NAME} ${PACKAGE_NAME} ! )package ${PACKAGE_NAME};#end /** * ${DESCRIPTION} * * author ${USER} * date ${DATE} ${TIME} */ public class ${NAME} { }这里${USER}取的是系统用户名${DATE}和${TIME}是当前日期时间。团队协作时我建议把${USER}换成固定的团队标识或者干脆去掉避免提交记录里出现五花八门的用户名。File Template 还有一个隐藏用法自定义文件类型模板。比如项目里经常要建 Mapper XML我可以定义一个MyBatis Mapper XML模板新建时直接生成带 namespace、resultMap 骨架的 XML省去每次复制粘贴再改 namespace 的麻烦。2.3 Postfix Completion在表达式后面接操作Postfix Completion 是很多人忽略的功能。它的用法是在一个表达式后面敲.加缩写然后 Tab 展开。比如list.for展开成 for 循环str.if展开成 if 判断。路径在Settings Editor General Postfix Completion。我自定义了几个obj.nn展开成if (obj ! null) { }obj.cast展开成强制类型转换。这个功能的价值在于不打断编码思路——你正在写一个表达式想到要判空直接在后面接.nn就完事不用把光标移到前面去写 if。2.4 这三者的组合拳怎么打单独看每个功能都不复杂组合起来才见威力。我的日常流程是新建文件用 File Template 出骨架写方法体时用 Live Template 补高频片段写表达式时用 Postfix Completion 接操作。三层配合下来一个普通 Service 方法的编写时间能压缩一半以上。但这里有个前提模板要跟着项目规范走。我见过有团队每个人都有自己的 Live Template结果代码风格五花八门。正确做法是把模板配置导出成配置文件纳入版本管理团队统一导入。IDEA 支持在File Manage IDE Settings Export Settings里导出模板配置新人入职直接导入省去逐个配置的麻烦。3. 进阶层从数据库表结构一键生成实体3.1 Database 工具窗口的连接配置IDEA 旗舰版自带 Database 工具窗口社区版没有这是选版本时要考虑的。配置路径在右侧边栏的Database面板点号选数据源类型填主机、端口、库名、用户名密码。连接配置有几个细节值得说。第一是驱动下载第一次连接时 IDEA 会提示下载驱动点一下就行不用手动找 jar 包。第二是时区设置MySQL 连接经常报时区错误在Advanced标签页把serverTimezone设成Asia/Shanghai就能解决。第三是只读连接如果只是用来生成代码建议勾上Read-only避免误操作改到数据。连接成功后左侧会列出所有库和表。展开表能看到字段、类型、注释、索引这些信息就是代码生成的原料。3.2 Generate POJOs最省事的实体生成右键点击表选Scripted Extensions Generate POJOs.groovy会弹出一个对话框让你选输出目录和包名确认后直接生成实体类。默认模板会生成字段、getter/setter、toString字段类型按数据库类型映射比如varchar映射成Stringint映射成Integer。这个功能开箱即用但默认模板有几个地方不符合我的习惯一是没加 Lombok 注解生成一堆 getter/setter二是没带字段注释数据库里的comment没被利用三是日期类型默认用java.sql.Timestamp我习惯用java.time.LocalDateTime。这些都能通过改模板解决下一节细说。3.3 自定义 Groovy 模板让生成的代码符合项目规范Generate POJOs.groovy本身就是一个 Groovy 脚本位置在 IDEA 安装目录的plugins/DatabaseTools/lib下但更推荐的做法是复制一份到项目里改通过Scripted Extensions Go to Scripts Directory找到用户脚本目录把脚本放进去。我改过的模板核心逻辑是这样的遍历表的每一列取列名转驼峰、取类型做映射、取注释做字段说明。关键代码片段def className table.getName().toLowerCase().split(_).collect { it.capitalize() }.join() def fields table.getColumnObjects().collect { column - def fieldName column.getName().toLowerCase().split(_).collect { it.capitalize() }.join() fieldName fieldName.substring(0, 1).toLowerCase() fieldName.substring(1) def fieldType typeMapping[column.getTypeName()] [name: fieldName, type: fieldType, comment: column.getComment()] }类型映射我用一个 Map 维护def typeMapping [ varchar: String, char: String, text: String, int: Integer, bigint: Long, tinyint: Integer, decimal: BigDecimal, datetime: LocalDateTime, timestamp: LocalDateTime, date: LocalDate, bit: Boolean ]生成时套 Lombok 注解类上加Data字段上加Schema(description ...)如果项目用 Swagger。这样生成的实体类直接能用不用再手动改。提示改模板时先在测试库上跑确认生成结果符合预期再对生产库用。我有次模板里字段名转换写错把user_name转成了userName之外的东西生成了一堆编译不过的代码返工了半天。3.4 批量生成多张表的实体单表生成够用但接手新项目时往往要一次生成几十张表。Database 工具窗口支持多选按住 Ctrl 点选多张表右键Scripted Extensions Generate POJOs.groovy会依次生成所有选中表的实体。如果表特别多还可以用 Groovy 脚本直接遍历整个 schema。在脚本里拿到dataSource后遍历schema.getTableObjects()对每张表调生成逻辑输出到对应目录。这种方式适合初始化项目时一次性铺开但要注意排除系统表和日志表不然会生成一堆用不上的类。4. 扩展层用脚本批量生成整套骨架代码4.1 为什么实体生成还不够实体只是骨架的一部分。一个完整的业务模块还需要 Mapper 接口、Mapper XML、Service 接口、Service 实现、Controller、DTO、VO。如果每样都手动建实体生成省下的时间又被吃回去了。所以我把生成范围扩大到整套骨架。思路是以表结构为输入用一套模板批量产出所有层级的文件。实现方式有两种一是写一个独立的 Groovy 脚本在 IDEA 里跑二是用 FreeMarker 之类的模板引擎写个生成器。我选前者因为不用引入依赖脚本直接调 IDEA 的 API 拿表结构。4.2 模板设计一套变量驱动所有文件核心是把表名、类名、字段列表、包名这些变量抽出来每个文件模板都基于同一组变量渲染。我定义的变量集变量名含义示例tableName原始表名user_infoentityName实体类名UserInfoentityVar实体变量名userInfofields字段列表[{name, type, comment}]basePackage基础包名com.example.demo有了这组变量Mapper 接口模板就是package ${basePackage}.mapper; import ${basePackage}.entity.${entityName}; import com.baomidou.mybatisplus.core.mapper.BaseMapper; public interface ${entityName}Mapper extends BaseMapper${entityName} { }Service 接口、Controller 同理都是变量替换。这样一套模板改一处所有生成的文件同步生效。4.3 脚本实现遍历表、渲染模板、写文件脚本的主流程分四步连数据库拿表列表、遍历每张表构建变量、按模板渲染内容、写到目标目录。核心代码结构def tables getSelectedTables() // 从 Database 窗口拿选中的表 tables.each { table - def vars buildVars(table) // 构建变量集 [Mapper.java, Service.java, ServiceImpl.java, Controller.java].each { tpl - def content renderTemplate(tpl, vars) writeFile(buildPath(tpl, vars), content) } }renderTemplate里做简单的字符串替换把${entityName}这类占位符换成实际值。writeFile负责建目录、写文件注意文件已存在时要跳过或备份避免覆盖手写代码。注意批量生成前一定要确认输出目录正确。我有次包名配错生成的文件全写到默认包下清理了半天。建议脚本里加个 dry-run 模式先打印要生成的文件路径确认无误再真正写盘。4.4 生成后的收尾格式化与检查脚本生成的代码往往格式不规整缩进、空行、import 顺序都可能乱。我的做法是生成后统一跑一遍 IDEA 的格式化全选文件按CtrlAltL或者用Code Reformat Code批量处理。如果项目配了 Checkstyle 或 SonarLint再跑一遍静态检查把明显的规范问题修掉。这一步不能省。生成器吐出来的代码如果格式混乱review 时会被挑刺反而增加沟通成本。花两分钟格式化省下的是后面反复修改的时间。5. 常见问题与排查技巧实录5.1 生成代码编译不过的几类原因现象可能原因排查方法找不到符号包名或 import 配错检查模板里的 basePackage 变量类型不匹配数据库类型映射缺失补全 typeMapping 里的类型注解报红依赖未引入确认 Lombok、Swagger 依赖在 pom 里字段名大小写错驼峰转换逻辑有 bug用user_name这类带下划线的字段测试类型映射是最容易出问题的地方。数据库里的tinyint(1)到底映射成Boolean还是Integer不同项目习惯不同。我的做法是在模板里加个开关默认映射成Integer需要布尔语义时手动改。另外decimal一定要映射成BigDecimal映射成Double会有精度问题这个坑我踩过。5.2 模板变量取不到值怎么办Groovy 脚本里取表名、列名、注释都有对应的 API但有些数据库的注释字段可能为空。比如某些表建的时候没写 commentcolumn.getComment()返回 null模板里直接拼就会出null字样。处理办法是加空值判断def comment column.getComment() ?: column.getName()用 Elvis 运算符给个兜底值。同理表名转类名时如果表名本身没有下划线split 后只有一个元素capitalize 后就是类名逻辑要兼容这种情况。5.3 生成的文件覆盖了手写代码这是最危险的问题。批量生成时如果目标文件已存在脚本直接写就会把手写逻辑冲掉。我的防护措施有三层一是脚本里判断文件存在就跳过并打印日志二是生成前先git status确认工作区干净出问题能回滚三是重要模块生成前先提交一次留个还原点。提示养成生成前先提交的习惯比任何防护脚本都可靠。我现在的流程是改表结构 → 提交当前代码 → 跑生成脚本 → 对比 diff → 手动合并业务逻辑。5.4 生成速度慢、卡顿的处理表特别多的时候脚本跑起来会卡。原因通常是每张表都重新查一次元数据或者每次都新建数据库连接。优化办法是复用连接在脚本开头建一次连接遍历所有表时共用。另外生成大量文件时关掉 IDEA 的实时索引File Power Save Mode能明显减少卡顿。5.5 团队协作时模板怎么统一模板配置散落在每个人本地是团队协作的隐患。我的做法是把脚本和模板文件放到项目仓库的tools/codegen目录下README 里写清楚怎么导入、怎么改。新人拉代码后按文档配置一次后续跟着仓库更新。这样模板的变更走 code review不会出现某个人本地模板改了但别人不知道的情况。6. 我踩过的坑和几条实在建议先说一个印象最深的坑。早期我用默认模板生成实体没注意日期类型映射生成的全是java.sql.Timestamp。项目里统一用LocalDateTime结果生成的类跟现有代码风格完全不一致review 时被打回重写。从那以后我养成了习惯改模板前先看项目里已有的类长什么样照着现有风格定模板而不是照着自己的偏好来。第二条建议是生成器只生成骨架业务逻辑永远手写。我见过有人把简单的查询逻辑也塞进模板结果生成出来的代码看似完整实际每个方法都要改改的成本比手写还高。生成器的价值在于消除重复的声明性代码不在于替代思考。第三条是模板要版本化。脚本、模板文件、类型映射配置全部纳入 git每次改动写清楚原因。这样模板出问题时能快速定位是哪次改动引入的也方便回滚。最后分享一个小技巧给生成脚本加一个预览参数跑的时候先打印所有要生成的文件路径和内容摘要确认无误再真正写盘。这个习惯帮我避免了好几次误覆盖尤其是接手陌生项目、表结构不熟的时候预览一遍能提前发现命名冲突和路径问题。这套流程跑顺之后一个新模块的骨架代码从建表到能跑起来基本控制在十分钟以内剩下的时间全花在业务逻辑上。工具的价值就在这儿——它不替你做决定但把重复劳动压缩到几乎可以忽略。
做 Java 开发这些年我见过太多团队把时间耗在重复的样板代码上一个实体类要手写 getter/setter、toString、equals/hashCode一个 Mapper 接口要照着表结构一个个字段敲Controller 里的增删改查方法几乎是复制粘贴改个名字。这些活儿不难但极其消耗耐心而且手写必然出错——少个字段、类型对不上、注解漏了编译能过但运行就炸。后来我把 IDEA 里那套代码生成能力彻底摸了一遍从内置模板到自定义脚本从单文件生成到批量产出硬是把一个模块的骨架代码从半天压缩到几分钟。这篇就聊聊我是怎么在 IDEA 里做到一键生成代码的包括工具选型、模板配置、脚本编写和踩过的坑适合已经会用 IDEA 但还没系统整理过代码生成流程的开发者也适合刚接手老项目、被样板代码淹没的朋友。1. 先想清楚为什么要在 IDEA 里做代码生成1.1 样板代码到底吃掉了多少时间我先算一笔账。假设一个中等规模的业务模块有 20 张表每张表对应一个实体类、一个 Mapper 接口、一个 Service 接口和实现、一个 Controller再加上 DTO 和 VO。实体类平均 15 个字段手写 getter/setter 就是 30 个方法加上 toString、equals、hashCode一个类轻松过 200 行。20 张表就是 4000 行纯样板代码。按熟练工每分钟写 3 行算光敲这些就要 20 多个小时还不算调试字段名拼错、类型写反的时间。更麻烦的是维护成本。表结构一改实体类要同步改Mapper 的 XML 要改DTO 要改稍不留神就漏了一处等到联调时才发现字段对不上。这种错误排查起来特别费劲因为编译期不报错运行时才暴露。所以代码生成不是为了炫技而是把机械劳动交给工具把人的精力留给真正的业务逻辑。1.2 IDEA 自带能力和第三方插件的边界在哪很多人一提到代码生成就想到装插件其实 IDEA 内置的能力已经覆盖了大部分场景。我把它分成三层来看层级能力适用场景是否需要插件基础层Live Template、File Template、Postfix Completion单文件、单段代码快速补全否进阶层Database 工具窗口的 Generate POJOs、Scripted Extensions从数据库表结构生成实体否扩展层第三方代码生成插件、自定义 Groovy 脚本批量生成多文件、复杂模板视情况基础层解决的是少敲几个字进阶层解决的是从表结构到实体扩展层解决的是整套骨架批量产出。我的建议是先把手头这三层吃透再决定要不要引入外部工具。很多团队一上来就找现成的代码生成器结果模板不贴合自己的项目规范改起来比自己写还费劲。1.3 选型背后的取舍逻辑为什么我最终选择IDEA 内置 Database 工具 自定义模板 Groovy 脚本这套组合而不是直接用某个开源代码生成框架原因有三个。第一是零外部依赖。内置工具跟着 IDEA 走不需要额外引入 jar 包不需要维护生成器的版本团队新人拉下代码就能用。第二是模板可控。生成出来的代码风格、包结构、注解习惯都能按项目规范定制不会出现生成器吐出来的代码和手写代码风格打架的尴尬。第三是调试直观。脚本在 IDEA 里直接跑报错信息清晰改一行看一行比在命令行里调生成器舒服得多。当然这套方案也有短板它更适合从数据库表结构出发的生成场景如果是从接口文档生成或者从 JSON 生成就得换思路。但对大多数 CRUD 为主的业务系统来说表结构就是源头这套组合够用了。2. 基础功把 Live Template 和 File Template 用到位2.1 Live Template把高频代码片段变成缩写Live Template 是我用得最多的功能没有之一。它的逻辑很简单你定义一个缩写敲缩写按 Tab就展开成一段预设代码。IDEA 自带了不少比如psvm展开成 main 方法sout展开成System.out.println()。但真正提效的是自定义模板。我举几个自己常用的例子。日志声明我定义缩写logd展开成private static final Logger log LoggerFactory.getLogger($CLASS_NAME$.class);其中$CLASS_NAME$是变量展开时会自动取当前类名。再比如单元测试方法缩写testmTest public void test$METHOD_NAME$() { // given // when // then }配置路径在Settings Editor Live Templates新建一个 Template Group然后在组里加模板。关键是变量要设对$CLASS_NAME$这种内置变量 IDEA 能自动推断自定义变量可以设默认值或者用表达式。注意Live Template 的缩写不要和已有缩写冲突比如你定义for就会覆盖内置的循环模板。我一般给自定义模板加个前缀比如xlog、xtest避免误触。2.2 File Template新建文件时自动套骨架File Template 解决的是新建一个类文件头、包声明、类注释、基础结构自动生成的问题。路径在Settings Editor File and Code Templates。我改过Class模板加上了作者、创建时间、功能描述#if (${PACKAGE_NAME} ${PACKAGE_NAME} ! )package ${PACKAGE_NAME};#end /** * ${DESCRIPTION} * * author ${USER} * date ${DATE} ${TIME} */ public class ${NAME} { }这里${USER}取的是系统用户名${DATE}和${TIME}是当前日期时间。团队协作时我建议把${USER}换成固定的团队标识或者干脆去掉避免提交记录里出现五花八门的用户名。File Template 还有一个隐藏用法自定义文件类型模板。比如项目里经常要建 Mapper XML我可以定义一个MyBatis Mapper XML模板新建时直接生成带 namespace、resultMap 骨架的 XML省去每次复制粘贴再改 namespace 的麻烦。2.3 Postfix Completion在表达式后面接操作Postfix Completion 是很多人忽略的功能。它的用法是在一个表达式后面敲.加缩写然后 Tab 展开。比如list.for展开成 for 循环str.if展开成 if 判断。路径在Settings Editor General Postfix Completion。我自定义了几个obj.nn展开成if (obj ! null) { }obj.cast展开成强制类型转换。这个功能的价值在于不打断编码思路——你正在写一个表达式想到要判空直接在后面接.nn就完事不用把光标移到前面去写 if。2.4 这三者的组合拳怎么打单独看每个功能都不复杂组合起来才见威力。我的日常流程是新建文件用 File Template 出骨架写方法体时用 Live Template 补高频片段写表达式时用 Postfix Completion 接操作。三层配合下来一个普通 Service 方法的编写时间能压缩一半以上。但这里有个前提模板要跟着项目规范走。我见过有团队每个人都有自己的 Live Template结果代码风格五花八门。正确做法是把模板配置导出成配置文件纳入版本管理团队统一导入。IDEA 支持在File Manage IDE Settings Export Settings里导出模板配置新人入职直接导入省去逐个配置的麻烦。3. 进阶层从数据库表结构一键生成实体3.1 Database 工具窗口的连接配置IDEA 旗舰版自带 Database 工具窗口社区版没有这是选版本时要考虑的。配置路径在右侧边栏的Database面板点号选数据源类型填主机、端口、库名、用户名密码。连接配置有几个细节值得说。第一是驱动下载第一次连接时 IDEA 会提示下载驱动点一下就行不用手动找 jar 包。第二是时区设置MySQL 连接经常报时区错误在Advanced标签页把serverTimezone设成Asia/Shanghai就能解决。第三是只读连接如果只是用来生成代码建议勾上Read-only避免误操作改到数据。连接成功后左侧会列出所有库和表。展开表能看到字段、类型、注释、索引这些信息就是代码生成的原料。3.2 Generate POJOs最省事的实体生成右键点击表选Scripted Extensions Generate POJOs.groovy会弹出一个对话框让你选输出目录和包名确认后直接生成实体类。默认模板会生成字段、getter/setter、toString字段类型按数据库类型映射比如varchar映射成Stringint映射成Integer。这个功能开箱即用但默认模板有几个地方不符合我的习惯一是没加 Lombok 注解生成一堆 getter/setter二是没带字段注释数据库里的comment没被利用三是日期类型默认用java.sql.Timestamp我习惯用java.time.LocalDateTime。这些都能通过改模板解决下一节细说。3.3 自定义 Groovy 模板让生成的代码符合项目规范Generate POJOs.groovy本身就是一个 Groovy 脚本位置在 IDEA 安装目录的plugins/DatabaseTools/lib下但更推荐的做法是复制一份到项目里改通过Scripted Extensions Go to Scripts Directory找到用户脚本目录把脚本放进去。我改过的模板核心逻辑是这样的遍历表的每一列取列名转驼峰、取类型做映射、取注释做字段说明。关键代码片段def className table.getName().toLowerCase().split(_).collect { it.capitalize() }.join() def fields table.getColumnObjects().collect { column - def fieldName column.getName().toLowerCase().split(_).collect { it.capitalize() }.join() fieldName fieldName.substring(0, 1).toLowerCase() fieldName.substring(1) def fieldType typeMapping[column.getTypeName()] [name: fieldName, type: fieldType, comment: column.getComment()] }类型映射我用一个 Map 维护def typeMapping [ varchar: String, char: String, text: String, int: Integer, bigint: Long, tinyint: Integer, decimal: BigDecimal, datetime: LocalDateTime, timestamp: LocalDateTime, date: LocalDate, bit: Boolean ]生成时套 Lombok 注解类上加Data字段上加Schema(description ...)如果项目用 Swagger。这样生成的实体类直接能用不用再手动改。提示改模板时先在测试库上跑确认生成结果符合预期再对生产库用。我有次模板里字段名转换写错把user_name转成了userName之外的东西生成了一堆编译不过的代码返工了半天。3.4 批量生成多张表的实体单表生成够用但接手新项目时往往要一次生成几十张表。Database 工具窗口支持多选按住 Ctrl 点选多张表右键Scripted Extensions Generate POJOs.groovy会依次生成所有选中表的实体。如果表特别多还可以用 Groovy 脚本直接遍历整个 schema。在脚本里拿到dataSource后遍历schema.getTableObjects()对每张表调生成逻辑输出到对应目录。这种方式适合初始化项目时一次性铺开但要注意排除系统表和日志表不然会生成一堆用不上的类。4. 扩展层用脚本批量生成整套骨架代码4.1 为什么实体生成还不够实体只是骨架的一部分。一个完整的业务模块还需要 Mapper 接口、Mapper XML、Service 接口、Service 实现、Controller、DTO、VO。如果每样都手动建实体生成省下的时间又被吃回去了。所以我把生成范围扩大到整套骨架。思路是以表结构为输入用一套模板批量产出所有层级的文件。实现方式有两种一是写一个独立的 Groovy 脚本在 IDEA 里跑二是用 FreeMarker 之类的模板引擎写个生成器。我选前者因为不用引入依赖脚本直接调 IDEA 的 API 拿表结构。4.2 模板设计一套变量驱动所有文件核心是把表名、类名、字段列表、包名这些变量抽出来每个文件模板都基于同一组变量渲染。我定义的变量集变量名含义示例tableName原始表名user_infoentityName实体类名UserInfoentityVar实体变量名userInfofields字段列表[{name, type, comment}]basePackage基础包名com.example.demo有了这组变量Mapper 接口模板就是package ${basePackage}.mapper; import ${basePackage}.entity.${entityName}; import com.baomidou.mybatisplus.core.mapper.BaseMapper; public interface ${entityName}Mapper extends BaseMapper${entityName} { }Service 接口、Controller 同理都是变量替换。这样一套模板改一处所有生成的文件同步生效。4.3 脚本实现遍历表、渲染模板、写文件脚本的主流程分四步连数据库拿表列表、遍历每张表构建变量、按模板渲染内容、写到目标目录。核心代码结构def tables getSelectedTables() // 从 Database 窗口拿选中的表 tables.each { table - def vars buildVars(table) // 构建变量集 [Mapper.java, Service.java, ServiceImpl.java, Controller.java].each { tpl - def content renderTemplate(tpl, vars) writeFile(buildPath(tpl, vars), content) } }renderTemplate里做简单的字符串替换把${entityName}这类占位符换成实际值。writeFile负责建目录、写文件注意文件已存在时要跳过或备份避免覆盖手写代码。注意批量生成前一定要确认输出目录正确。我有次包名配错生成的文件全写到默认包下清理了半天。建议脚本里加个 dry-run 模式先打印要生成的文件路径确认无误再真正写盘。4.4 生成后的收尾格式化与检查脚本生成的代码往往格式不规整缩进、空行、import 顺序都可能乱。我的做法是生成后统一跑一遍 IDEA 的格式化全选文件按CtrlAltL或者用Code Reformat Code批量处理。如果项目配了 Checkstyle 或 SonarLint再跑一遍静态检查把明显的规范问题修掉。这一步不能省。生成器吐出来的代码如果格式混乱review 时会被挑刺反而增加沟通成本。花两分钟格式化省下的是后面反复修改的时间。5. 常见问题与排查技巧实录5.1 生成代码编译不过的几类原因现象可能原因排查方法找不到符号包名或 import 配错检查模板里的 basePackage 变量类型不匹配数据库类型映射缺失补全 typeMapping 里的类型注解报红依赖未引入确认 Lombok、Swagger 依赖在 pom 里字段名大小写错驼峰转换逻辑有 bug用user_name这类带下划线的字段测试类型映射是最容易出问题的地方。数据库里的tinyint(1)到底映射成Boolean还是Integer不同项目习惯不同。我的做法是在模板里加个开关默认映射成Integer需要布尔语义时手动改。另外decimal一定要映射成BigDecimal映射成Double会有精度问题这个坑我踩过。5.2 模板变量取不到值怎么办Groovy 脚本里取表名、列名、注释都有对应的 API但有些数据库的注释字段可能为空。比如某些表建的时候没写 commentcolumn.getComment()返回 null模板里直接拼就会出null字样。处理办法是加空值判断def comment column.getComment() ?: column.getName()用 Elvis 运算符给个兜底值。同理表名转类名时如果表名本身没有下划线split 后只有一个元素capitalize 后就是类名逻辑要兼容这种情况。5.3 生成的文件覆盖了手写代码这是最危险的问题。批量生成时如果目标文件已存在脚本直接写就会把手写逻辑冲掉。我的防护措施有三层一是脚本里判断文件存在就跳过并打印日志二是生成前先git status确认工作区干净出问题能回滚三是重要模块生成前先提交一次留个还原点。提示养成生成前先提交的习惯比任何防护脚本都可靠。我现在的流程是改表结构 → 提交当前代码 → 跑生成脚本 → 对比 diff → 手动合并业务逻辑。5.4 生成速度慢、卡顿的处理表特别多的时候脚本跑起来会卡。原因通常是每张表都重新查一次元数据或者每次都新建数据库连接。优化办法是复用连接在脚本开头建一次连接遍历所有表时共用。另外生成大量文件时关掉 IDEA 的实时索引File Power Save Mode能明显减少卡顿。5.5 团队协作时模板怎么统一模板配置散落在每个人本地是团队协作的隐患。我的做法是把脚本和模板文件放到项目仓库的tools/codegen目录下README 里写清楚怎么导入、怎么改。新人拉代码后按文档配置一次后续跟着仓库更新。这样模板的变更走 code review不会出现某个人本地模板改了但别人不知道的情况。6. 我踩过的坑和几条实在建议先说一个印象最深的坑。早期我用默认模板生成实体没注意日期类型映射生成的全是java.sql.Timestamp。项目里统一用LocalDateTime结果生成的类跟现有代码风格完全不一致review 时被打回重写。从那以后我养成了习惯改模板前先看项目里已有的类长什么样照着现有风格定模板而不是照着自己的偏好来。第二条建议是生成器只生成骨架业务逻辑永远手写。我见过有人把简单的查询逻辑也塞进模板结果生成出来的代码看似完整实际每个方法都要改改的成本比手写还高。生成器的价值在于消除重复的声明性代码不在于替代思考。第三条是模板要版本化。脚本、模板文件、类型映射配置全部纳入 git每次改动写清楚原因。这样模板出问题时能快速定位是哪次改动引入的也方便回滚。最后分享一个小技巧给生成脚本加一个预览参数跑的时候先打印所有要生成的文件路径和内容摘要确认无误再真正写盘。这个习惯帮我避免了好几次误覆盖尤其是接手陌生项目、表结构不熟的时候预览一遍能提前发现命名冲突和路径问题。这套流程跑顺之后一个新模块的骨架代码从建表到能跑起来基本控制在十分钟以内剩下的时间全花在业务逻辑上。工具的价值就在这儿——它不替你做决定但把重复劳动压缩到几乎可以忽略。
核心架构与实战)
