EasyCode实战：从IDEA插件到自定义模板，彻底告别重复CRUD代码

做新项目最怕什么？我现在的答案不是业务逻辑复杂，而是大量结构完全一致的 CRUD 代码要在十几个文件里反复手敲。一个表建完之后，实体、Mapper、Service、ServiceImpl、Controller、XML 哪个字段改了就是一串文件联动着改，改完还得纠结点开头是不是小写、下划线有没有去掉。这种活儿干久了，找一个靠谱的代码生成工具就是迟早的事。我之前在 IDEA 插件市场翻到 EasyCode，实际用了两三个项目后，基本把它固定成开新项目的第一批配置项了。这篇东西就是我自己从安装、跑通到改造模板的一整套实战记录，适合正在被重复代码折磨的 Java 后端开发，也适合准备把代码生成器纳入团队的负责人参考。

1. 从“重复手敲”到“一键生成”：EasyCode 解决的到底是什么问题

1.1 一个数据表牵扯出的文件清单

我举一个最常见的例子。假设业务里要维护一张user_info表，字段大概十几个：id、用户名、手机号、状态、创建时间、更新时间等等。放在传统 MyBatis 项目里，一个表要出活，最少得碰下面这些文件：实体类、DAO 接口、Mapper XML、Service 接口、Service 实现类、Controller。稍微规范化一点，还要再加查询条件对象、DTO、VO，文件数量直接翻倍。

十几个字段，意味着实体类里十几个私有属性，每个属性三件套：注释、声明、getter/setter。Mapper XML 里的 resultMap 要把字段映射一个个列出来，insert、update、selectByPrimaryKey 也基本是体力活。如果项目还没接 Lombok，实体类光 getter 和 setter 就得几十行。这些都是肉眼可见的死代码，不是说它们没有存在价值，而是它们不应该由人来反复输入。

我有段时间统计过，一个新模块如果建三张表，光这几个基础文件手写就要一整个下午，而且很容易出现低级错误，比如 XML 里少了个字段、实体类类型和数据库类型对不上、某个表字段忘了加注释。代码生成工具恰恰就是为这个场景设计的，它要把“数据库表结构”这一份信息，转化为多份符合工程习惯的代码文件，而且转化规则要能自定义。

1.2 EasyCode 在这条链路里的定位

EasyCode 是 IDEA 插件市场里的一款免费代码生成工具，它做的事情很聚焦：先读取你在 IDEA Database 工具窗口里配置好的数据库表结构，再按照你选的模板去渲染出实体、Mapper、Service、Controller 等文件。它本身不是一个在线代码生成网站，也不是一个独立的命令行脚手架，而是长在 IDEA 里，和编辑器深度配合。

理解它的定位，可以用一个类比：手写 CRUD 代码像是手工砌墙，每一块砖都要自己搬；代码生成器则像是先做了一批规格统一的预制板，到现场拼装就行。预制板不能解决所有建筑问题，但能把最重复、最标准的墙体部分快速搞定。EasyCode 解决的就是 Java Web 项目里最标准化的那一层：数据库模型到基础接口的映射。

它的核心能力我总结成三点：一是以数据库表为输入源，天然保证字段名、类型、注释与库表一致；二是模板可改，输出结构能跟着团队规范走；三是支持单表生成和批量生成，适合初始化新模块。后面的章节里，我基本都围绕这三点展开。

2. 安装与前置准备：让插件能“看到”你的数据库

2.1 安装插件和激活模板入口

安装本身很简单，IDEA 里打开 Settings / Plugins，切到 Marketplace 搜索 EasyCode，看到名字匹配的插件直接 Install，然后重启 IDE。但这里我有必要提醒一句：插件市场里搜“EasyCode”可能会出现名称相近、功能不同的结果，我建议认准那个图标和你搜的关键词严格一致的版本。装错的情况下，最常见的问题是右键数据表根本找不到 EasyCode 菜单，或者设置面板里看不到模板配置，这种时候先别急着怀疑插件坏了，先确认装的是不是同一个东西。

安装完成并重启后，IDEA 的设置面板里一般会多出 EasyCode 相关配置项，比如“设置存储路径”“模板组”“全局配置”等。某些版本在 Settings 的 Other Settings 下面，某些版本在 Tools 下面，找不到的时候直接用设置搜索框输入 EasyCode 更省事。

我见过有人装完插件以后不做任何配置就直接去连数据库，结果右键表的时候一脸懵，因为 EasyCode 是依赖 IDEA 自带 Database 工具窗口读取表结构的。换句话说，插件只是渲染引擎，数据源连接才是它的眼睛。所以接下来这步才是真正的重点。

2.2 IDEA Database 连接配置的三个关键点

使用 EasyCode 之前，必须先把数据库连接配置好。以 MySQL 为例，在 IDEA 右侧打开 Database 工具窗口，点加号，选择 Data Source 下的 MySQL，填主机、端口、账号、密码，然后点 Test Connection。第一次配置时 IDEA 通常会提示缺少驱动，让你下载，直接下载即可；如果所在网络环境不方便自动下载，也可以手动下载驱动 JAR 包，在数据源配置里通过“Driver”下拉按钮的加号导入本地文件。

这里有三个细节决定你后面能否顺利生成：

第一，连接串里的参数建议写完整。MySQL 连接 URL 至少带上useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai，不然可能遇到中文注释乱码、日期时间类型读取异常。如果数据库需要 SSL，相关参数按需加上即可。

第二，务必选中正确的 Schema。很多 MySQL 实例里同时存在多个数据库，IDEA 连接后会在连接下面列出所有 Schema。如果你右键的是连接主节点，看到的是 Schema 列表而不是具体的业务表，EasyCode 自然没有可用的生成目标。正确做法是展开到业务库，看到里面真实的业务表之后，再去右键表。

第三，检查是否能把表结构完整刷出来。如果某个表在 Database 里能看到表名，但展开后字段列表刷新不出来，多半是当前数据库账号权限不足，或者数据库版本和驱动版本不太兼容。这种情况建议先在 Database 工具窗口里确认字段能正常展示，再去启动生成，否则生成出来的文件字段可能不完整。

还有一个小经验：不要同时开多个数据库连接然后右键乱选。生成前把当前使用的连接折叠到只剩目标业务库这一条，既能减少误操作，也能避免生成时因为连接切换导致选中了错误的表。

3. 第一次实战：选中表，生成一套标准 CRUD

3.1 生成入口和参数填写

数据库连接没问题之后，首次跑通就很快了。操作路径大致是这样的：在 Database 工具窗口里展开目标数据库，选中一张表，比如user_info，右键，在弹出的菜单里找到 EasyCode 菜单项，选择 Generate Code。

点击之后会弹出一个配置窗口，我第一次用的时候在这个窗口里停留了好一会儿，因为它不是简单的“下一步下一步”，而是有不少会影响输出结果的选项。我遇到的主要选项和填写逻辑如下：

• 模块（Module / Model）：要生成的文件放在哪个代码模块里，多模块项目注意选对，别生成到公共模块去了。
• 基础包名（Package）：比如com.example.demo，生成的时候会基于它拼接entity、mapper、service、controller等子包。
• 分组名（Group）：一般填业务模块名，比如user，有时也写成表名，看团队约定。
• 模板组（Template Group）：这里要选择用哪一套模板来生成，默认就是插件的默认模板组。

有的版本里还会让你选择需要生成的栏目，比如勾选 Entity、Mapper、Service 等。默认全选一般没问题，但如果只是临时需要实体类，可以只勾对应栏目，减少无效文件产生。

确认配置后点击 OK，IDEA 会在你选择的目录下生成文件。如果是第一次用，建议先只拿一个表试跑，不要急着批量，先在 IDE 里看一眼生成的 Java 文件能不能编译、包名对不对，确认没问题再放量，这样即使出错也能快速定位是配置问题还是模板问题。

3.2 生成后的目录与代码长什么样

拿user_info表举例，生成的目录结构通常是这样的：

com/example/demo/ ├── controller/UserInfoController.java ├── entity/UserInfo.java ├── mapper/UserInfoMapper.java ├── service/UserInfoService.java └── service/impl/UserInfoServiceImpl.java

如果有启用 XML 模板，Mapper XML 一般还会生成到resources/mapper/UserInfoMapper.xml，具体路径由模板决定。实体类里，id字段会映射成Long id或Integer id，create_time会映射成LocalDateTime createTime，字段名从下划线转成驼峰，数据库字段注释会变成 Java 注释。Mapper 接口里会有基础的增删改查方法声明，XML 会对齐生成 SQL，Service 接口和实现类则把这些方法包一层，Controller 提供 RESTful 入口。

整体上，这一套文件放在 Spring Boot 项目里通常能直接开机跑通，至少编译层面不会有大问题。需要提醒的是，不同版本的 EasyCode 默认模板细节有差异，可能默认输出的是纯 MyBatis 风格，也可能部分模板里带了分页插件的写法。所以“长什么样”这件事，建议以实际生成结果为准，我这里是告诉你应该重点检查哪些信息：包名、类名、字段类型、注释对齐情况。

3.3 批量生成多表时的注意事项

单表跑通后，批量生成能让我一下子解放出来。操作入口通常是多选表之后右键，选择 EasyCode，或者使用 Generate All Code 之类的菜单，配置方式和单表类似。

批量生成最值得注意的其实是命名规范。EasyCode 是把user_info转成UserInfo，但如果数据库里表名本身就混乱，比如有的叫userInfo、有的叫userinfo、有的带模块前缀，生成出来的类名就会非常难看。批量之前建议先统一库表命名规则，这不仅是数据库规范问题，也是生成器能不能稳定工作的前提条件。

还有一个细节：批量勾选表的时候，可能有些表只是中间表、临时表，并不需要生成全套 CRUD。批量操作前先过滤一遍，避免生成一堆没用的 Controller 污染项目目录。我自己的做法是先按业务模块分批生成，一批一个包名，宁可多右键几次，也不一次性全选几十张表，这样出现问题时排查范围也小。

4. 模板才是灵魂：把 EasyCode 调教成团队专属生成器

4.1 默认模板拆解：每个文件各司其职

EasyCode 能从一个通用插件变成项目级生产力工具，关键就在模板配置。插件内置的默认模板通常包含entity.java、mapper.java、service.java、serviceImpl.java、controller.java、mapper.xml这些模板文件，每一个模板负责生成一个类型的文件。从名字就能看出来，这套默认设计是围绕经典 MyBatis 三层结构来的。

模板本身的语法是基于 Velocity 这类模板引擎的，它允许你在文本文件里嵌入变量和循环逻辑。比如实体模板会遍历表的字段列表，为每一个字段生成属性声明和注释；Mapper XML 模板会遍历字段生成 resultMap；Controller 模板则会根据表名生成请求路径。

我刚开始也是直接用默认模板，后来发现一个问题：默认模板的代码风格是插件作者的习惯，不一定是团队的习惯。比如有些团队统一要求 Controller 返回一个R<T>包装对象，有些团队要求 Service 接口上写注释，有些团队要求在实体类上统一加逻辑删除注解。这些诉求，默认模板给不了，只能靠改模板实现。

4.2 自定义一个 Controller 模板的实际例子

这里我拿自定义 Controller 模板举个例子。假设团队要求所有接口返回统一结果包装R<T>，并且要求生成基础的列表和详情方法。那 Controller 模板大致可以写成这样：

package ${packageName}.controller; import ${packageName}.entity.${tableInfo.obj.name}; import ${packageName}.service.${tableInfo.obj.name}Service; ... import org.springframework.web.bind.annotation.*; import javax.annotation.Resource; @RestController @RequestMapping("${tableInfo.obj.name.toLowerCase()}") public class ${tableInfo.obj.name}Controller { @Resource private ${tableInfo.obj.name}Service ${tableInfo.obj.name.toLowerCase()}Service; @GetMapping("/list") public R list() { return R.ok(${tableInfo.obj.name.toLowerCase()}Service.listAll()); } @GetMapping("/{id}") public R detail(@PathVariable Long id) { return R.ok(${tableInfo.obj.name.toLowerCase()}Service.getById(id)); } }

这段模板在我实际项目中基本能工作，但有一点必须提醒：不同版本插件对变量的定义方式可能略有区别，比如表名对应的驼峰类名变量、包名变量、作者变量，在不同版本里可能叫$tableInfo.obj.name，也可能简写成了别的名称。所以正确做法是先在模板配置面板里看一下当前版本的变量提示，再写正式模板。不要直接拿别人仓库里的模板文件硬套，否则很容易出现模板里引用了不存在的变量，生成出来一堆空值。

修改完模板之后，记得切换到“模板组”保存，并且在生成前选中当前模板组。我最初犯过几次低级错误：改完模板直接生成，结果生成的还是旧内容，后来才反应过来，模板编辑窗口只保存了文件内容，没有真正切换生成时使用的模板组。

4.3 模板里的核心变量与常用技巧

EasyCode 模板里最常用的一组信息，我整理成表格方便对照：

注意我用的是“常见写法”，因为不同版本提供的变量名可能不完全一样。拿到新环境后，我一般会在模板里先写一个输出所有变量的调试模板，生成一次，看看有哪些变量可用，再开始正式改造。

模板里能用#foreach循环，比如遍历$tableInfo.fullColumn生成实体属性；能用#if做条件判断，比如判断字段是不是主键，决定是否生成@Id注解；也支持在模板里拼接字符串。掌握这三个能力，就能处理大部分自定义需求了。哪怕只是把注释、注解、导包风格统一一下，模板的价值就已经很高了。

5. 类型映射与命名转换：决定生成结果是否像“人写的”

5.1 默认映射表与修改入口

生成代码里最容易被忽视但影响最大的是类型映射。数据库里一个字段类型没映射对，生成的 Java 代码可能编译报错，或者虽然能编译，但类型选得很别扭。EasyCode 在全局配置里通常会有一个 Java 类型映射表，把数据库类型映射成 Java 类型，我自己常用的映射逻辑大致如下：

这套映射可以从数据库字段类型出发，保证生成的实体字段类型不会离谱。修改类型映射的入口一般在 EasyCode 的全局设置里，找到类型映射配置后，增删改都很直观。我建议团队统一维护一份映射配置，避免有人单独加了小众映射，结果生成代码风格漂移。

5.2 命名规则：驼峰转换背后的细节

表名user_info变成UserInfo，字段user_name变成userName，这套驼峰转换是生成器的基本功。但“去下划线”并不代表一切命名问题都解决。实际项目里常见的命名干扰有两种：一种是表名带前缀，比如t_user_info，如果模板不处理，类名会变成TUserInfo，看起来像临时变量；另一种是字段名带前缀缩写，比如u_name，转换后可能变成uName，很不优雅。

解决办法一般是利用插件提供的表前缀/字段前缀配置，或者在模板里写一个字符串处理函数。我自己的偏好是尽量在模板里做一次“去掉前缀”的处理，因为模板可控性更强，也可以兼容所有项目。具体写法要看你当前版本的模板引擎函数支持情况，建议先小规模实验再全面铺开。

5.3 边界类型：JSON、枚举、Decimal 怎么处理

除了常规的类型映射，还有几个边界类型值得单独说。

第一种是 JSON 字段。MySQL 里有时候会把复杂结构化数据存在 JSON 字段里，默认映射只会把它当成 String 处理。如果你希望实体里直接用一个自定义类型接收 JSON，光改类型映射是不够的，还要在模板里为字段增加相应注解和依赖。更常见的做法是先用 String 接收，在 Service 层做反序列化，这样生成器保持不变，业务逻辑单独处理。

第二种是枚举字段。数据库通常用 int/varchar 存枚举值，直接生成成 Integer 或 String 是最稳妥的。如果你从一开始就明确这个字段要用 Java 枚举，那可以修改模板，对某些字段类型做条件判断生成枚举引用。但我不建议把这类判断写得太复杂，否则模板维护成本会变得很高。生成之后再在实体里手动替换成枚举类型，往往比折腾模板更高效。

第三种是 decimal 和金额字段。金额字段用 decimal 是最常见的，Java 侧用 BigDecimal 也很标准。但如果你是配合前端使用，有些团队会倾向用 String 接收避免精度问题。这种偏好在模板里可以全局统一处理，把 decimal 直接映射成 String。关键是提前定好规则，不要一个项目里有的地方用 BigDecimal、有的地方用 String。

6. 生成失败的常见原因与完整排查链路

6.1 插件右键菜单消失或“不能生成”

很多人装上插件后右键表，发现菜单里根本没有 EasyCode，或者菜单是灰的。遇到这种情况别急着重装，按下面这个链路排查一遍比较高效：

第一步，打开 IDEA 右侧的 Database 面板，确认数据源是否已经连接成功，展开到能看到业务表的那一层。如果连接上有红色感叹号或者表字段刷不出来，先去修数据库连接问题。

第二步，确认右键时选中的是“表”本身，而不是数据库连接、Schema 目录或者某个字段。EasyCode 的生成入口一般挂在表节点上，右键位置不对，菜单自然不出现。

第三步，打开 Settings，用搜索框搜 EasyCode，看看插件的配置面板能不能正常打开。如果配置面板都打不开，可能是插件版本与 IDE 版本不兼容，建议根据 IDE 版本到插件市场下载对应的兼容版本。

第四步，查看 IDEA 日志。Help -> Show Log 里能看到插件运行时的异常堆栈，很多模板或配置层面的报错会记录在那里。日志里的关键行虽然不一定能直接告诉你改哪个参数，但至少能帮你定位到是“读取表结构失败”还是“模板渲染失败”。

6.2 模板配置报错与代码内容不符合预期

模板能跑，但生成出来的 Java 文件问题一堆，是最折磨人的阶段。我遇到过的典型情况有三类：

第一类是模板改了但生成结果没变。多数是没切换模板组，或者编辑模板时保存到错误的模板组里。我的排查方法是生成前截图看一眼模板组的名字，再对比配置面板里当前激活的模板组，名字不一致就是这里的问题。

第二类是生成后 Java 文件编译不通过。常见原因是类型映射没有配置，比如 MySQL 的datetime没有映射到任何 Java 类型，生成的实体就可能出现奇怪的类型。排查时先看实体类里字段的类型，再回头看类型映射表，一般十分钟内能定位。

第三类是模板语法错误。Velocity 模板里#if和#end不配对是最常见的低级错误，模板一多就容易漏。插件通常会在生成时弹出错误提示，但提示不够直观。我的习惯是每次改模板都用最小样例试跑：先只生成一张只有一个字段的临时表，确认模板能通过，再造真实的表来验证。

6.3 文件覆盖与丢失问题的防呆做法

批量生成还有一个很容易踩的坑：重复生成导致文件被覆盖。如果不小心第二次生成时改了模板，原来手工微调过的代码会被整体替换掉。EasyCode 生成时一般会提示文件已存在，问你是否覆盖，但手一快就会点成全选覆盖。

所以我把自己的生成流程固定成了三步：生成前先看一眼生成目录；生成时如果只是微调模板，优先生成到临时目录做对比；确认最终结果没问题之后，再正式生成。对于已经进入手写维护阶段的文件，我干脆在模板里做排除，让某些文件不重复生成。

另一个更稳妥的思路是把“自动生成的代码”和“手写业务代码”分目录管理。自动生成的接口、实体放一个包，手写的实现和扩展放另一个包，即使重新生成，也不会把手写的逻辑冲掉。这个思路比依赖 IDEA 的覆盖确认更可靠，也更好维护。

7. 个人实践：模板统一管理后我总结的几条建议

7.1 把模板放进 Git 仓库

代码生成器的模板本质上也是代码，而且是会影响所有模块风格的代码，我强烈建议纳入版本管理。EasyCode 的模板通常支持导出和导入，导出成压缩文件之后，我一般是单独放到一个仓库或目录里，和项目代码分开管理。

这样做有几个实实在在的好处：第一，换电脑或者装新环境时，不用重新调模板；第二，模板改动有记录，回滚容易；第三，新同事入职之后，导入一份模板就能和团队生成风格保持一致。那些“为什么我生成的代码和他生成的不一样”的争论，基本就消失了。

7.2 收敛“临时改生成结果”的做法

用上生成器一段时间后，我发现自己有个不良习惯：生成完的代码总觉得不够完美，于是直接在生成文件里手工改。改一次两次没问题，改多了就会出问题，因为下次重新生成时手工改动全丢了，而且明明改了，模板里还是老样子。

后来我纠正成另一个思路：如果某个生成文件需要手动调整才能用，那就说明模板不够好，宁可花时间把模板改好，也不要容忍“生成后再改”的流程。模板的一次修改，换来的是以后所有同类文件都正确。模板里写不出来的复杂业务逻辑，就不应该放进生成范围内，实体和基础接口适合生成，业务逻辑留手写反而更干净。

7.3 与 MyBatis-Plus 等框架搭配的取舍

现在很多人项目里用 MyBatis-Plus，EasyCode 和它是可以配套的，但默认模板不一定是为 MP 准备的。如果团队用 MP，通常会希望 Mapper 接口直接继承BaseMapper<T>，这样单表 CRUD 就完全不用写 XML。这件事靠自定义模板就能实现，把模板里的 Mapper 接口改成继承BaseMapper，并把 XML 相关的重复 SQL 简化掉即可。

取舍的核心原则是：模板服务于项目现状，而不是项目去迁就模板。不要因为默认模板生成了一大堆 XML 就觉得必须用 XML，也不用因为用了 MP 就把所有模板推翻。先明确项目里哪些部分需要自动化，哪些部分保持手写，再针对性改模板。我在实际项目里的配比是三张基础模板自动生成，业务层和查询条件单独手写，这样最能平衡效率和可控性。

最后再分享一个小习惯：每次升级 IDEA 或者换版本后，我会先用临时表跑一次生成，确认插件和模板都没失效，再正式动手。生成器这种工具，用顺手了很难放手，但它和 IDE 版本、模板引擎版本的兼容性需要一直盯着，把它当成一个长期维护的开发资产来对待，才不会被它拖后腿。