爬一手好线杆1. 项目背景与痛点分析
Ruoyi作为国内广泛使用的开源快速开发框架，其前后端分离版本在企业级应用开发中占据重要地位。在实际项目开发中，代码生成器是提升开发效率的利器，但原生的MyBatis-Plus代码生成脚本存在几个典型问题：
- 格式混乱：生成的Java文件缩进不一致，注释格式不统一
- 冗余代码：包含大量不必要的空行和模板注释
- 风格不符：与团队编码规范存在冲突，需要二次调整
- 扩展困难：自定义模板时需要修改多处硬编码配置
我在三个大型项目中实施Ruoyi框架时发现，开发人员平均需要花费15%的时间手动调整生成代码的格式。这种重复劳动不仅降低效率，还容易引入人为错误。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术方案设计
2.1 整体改造思路
基于MyBatis-Plus 3.5.1+版本的核心生成器进行扩展，主要改进点包括：
java复制// 改造后的生成器配置示例
FastAutoGenerator.create(dataSourceConfig)
.globalConfig(builder -> {
builder.author("yourname")
.outputDir("D://generated")
.enableSwagger()
.fileOverride();
})
.templateConfig(builder -> {
builder.controller("/templates/controller.java");
})
.injectionConfig(builder -> {
builder.customMap(Collections.singletonMap("date", LocalDate.now()));
});
关键改进策略：
- 采用链式API替代XML配置
- 引入模板引擎动态渲染
- 集成Prettier代码格式化
- 自定义注释生成规则
2.2 核心组件选型
| 组件 | 版本 | 作用 |
|---|---|---|
| MyBatis-Plus Generator | 3.5.2 | 基础代码生成 |
| Velocity | 2.3 | 模板渲染 |
| JavaParser | 3.24.2 | AST分析 |
| Prettier Java | 1.6.2 | 代码格式化 |
选择Velocity而非Freemarker的原因在于其更轻量，且Ruoyi原有模板体系基于Velocity构建。JavaParser用于生成后AST级别的代码结构调整，比正则表达式更可靠。