一句话先给结论：
若依的代码生成器，本质就是把你 80% 的体力活，变成 20% 的点点点。
会用的人，下班准点；不会用的人，加班到秃。

今天这篇文章，我不讲概念、不画大饼、不念官方文档，就从一个真实打工 Java/Vue 程序员的视角，把这些事一次性讲清楚：

• 若依代码生成到底 生成了什么
• 每一份代码 是干嘛用的
• 怎么改，才不会 生成一次，改一天
• 为什么你觉得它“鸡肋”，而别人却当神器
• 企业项目里，真正正确的用法

看完你会有一种感觉：
“原来我之前是在手搓原始人代码。”

---

一、为什么「代码生成」是若依的灵魂功能？

我们先说一句大实话。

你在公司每天写的代码，有多少是这种？

• 增删改查
• 分页
• 条件查询
• 表单校验
• 列表 + 弹窗
• Controller / Service / Mapper 三件套

这些代码有任何技术含量吗？

没有。

但你不写，功能就跑不起来。

这就是现实。

---

❌ 没用代码生成之前

一个最普通的“设备表”功能，你要写：

• SQL 表结构
• 实体类
• Mapper XML
• Mapper 接口
• Service
• ServiceImpl
• Controller
• 前端 API
• Vue 列表页
• Vue 新增 / 编辑页
• 校验规则
• 字典翻译

⏱️ 保守估计：1～2 天

---

✅ 用了若依代码生成之后

你只做三件事：

1️⃣ 设计数据库表
2️⃣ 点“生成代码”
3️⃣ 微调业务逻辑

⏱️ 30 分钟起步

所以你目前清楚了：
若依不是后台框架，是“效率放大器”。

---

二、若依代码生成器，到底是个什么东西？

一句人话解释：

若依代码生成 = 数据库表 → 一整套前后端工程代码

它不是“帮你写几行 Java”，而是直接给你：

层级	自动生成内容
数据层	Entity / Mapper / XML
业务层	Service / Impl
接口层	Controller
前端	Vue 页面 + API
配置	权限、菜单、字典

是真·可跑·可用·可维护

---

三、生成前最重大的一步：表结构设计（90% 的人死在这）⚠️

⚠️ 重点来了：

❗代码生成好不好用，不在生成器，在你的表设计

一个「正确的若依友善表」应该长这样

CREATE TABLE sys_device (
  id bigint NOT NULL COMMENT '主键',
  device_name varchar(100) COMMENT '设备名称',
  device_type varchar(50) COMMENT '设备类型',
  status char(1) COMMENT '状态（0正常 1停用）',
  create_time datetime COMMENT '创建时间',
  update_time datetime COMMENT '更新时间',
  remark varchar(500) COMMENT '备注',
  PRIMARY KEY (id)
);

---

三个血泪教训

❌ 1. 字段名乱起

devNm、dev_tp、st

生成出来你自己都看不懂

✅ 提议：

• 全英文
• 驼峰语义
• 一眼能看懂

---

❌ 2. 注释不写

不写注释 = 前端页面字段名是拼音 or 英文

注释 = 前端中文字段名

---

❌ 3. 不用通用字段

若依默认识别：

• create_time
• update_time
• create_by
• update_by
• remark

用这些字段 = 自动帮你处理
不用 = 自己写逻辑

---

四、点一下「生成代码」，到底发生了什么？⚙️

你在页面点“生成”，后台实则干了四件事：

① 解析表结构

• 字段名
• 类型
• 注释
• 是否主键

② 套 Freemarker 模板

• Java 模板
• Vue 模板
• SQL 模板

③ 输出到指定模块

• ruoyi-admin
• ruoyi-system
• ruoyi-ui

④ 自动注册菜单 & 权限

• 菜单树
• 按钮权限
• 接口权限

这一步，许多人一辈子没意识到有多爽。

---

五、生成出来的代码，分别是干嘛的？

我们按“你最常改的地方”来讲。

---

1️⃣ Entity（实体类）

public class SysDevice {
    private Long id;
    private String deviceName;
    private String deviceType;
    private String status;
}

特点：

• 已加好 @Excel
• 已加好 @ApiModelProperty
• 已对接前端

99% 情况下，不用动

---

2️⃣ Mapper + XML

<select id="selectSysDeviceList">
    SELECT * FROM sys_device
</select>

用途：

• 动态 SQL
• 复杂查询
• 联表

企业项目里，80% 的改动在这

---

3️⃣ Service / Impl

public List<SysDevice> selectSysDeviceList(SysDevice device)

用途：

• 写业务逻辑
• 校验
• 状态流转

这是你真正“写代码”的地方

---

4️⃣ Controller（接口）

@GetMapping("/list")
public TableDataInfo list(SysDevice device)

已内置：

• 分页
• 权限
• 日志

新手最容易犯错：乱加接口

---

5️⃣ Vue 页面（重点）

生成出来就是：

• 搜索区
• 表格
• 分页
• 新增弹窗
• 编辑弹窗

Element UI 全套

你最常改的是：

• 校验规则
• 字典绑定
• 列表展示样式

---

六、为什么有人说“代码生成没用”？

我给你翻译一下真实缘由：

❌ 缘由 1：生成完就乱改

• Controller 改逻辑
• XML 不会写
• 前端直接删

最后：生成 ≈ 没生成

---

❌ 缘由 2：业务复杂就弃用

• 一对多
• 树结构
• 状态机

实际真相：
生成器负责“骨架”，不是“脑子”

---

❌ 缘由 3：不懂它的边界

若依代码生成 ≠ 自动完成项目
若依代码生成 = 标准 CRUD 起跑线

---

七、企业项目中，正确的用法是这样

✅ 标准流程

1️⃣ 表设计 → 符合规范
2️⃣ 用生成器生成 完整模块
3️⃣ 只在 Service / XML 写业务
4️⃣ 前端只改样式，不重构结构

---

✅ 哪些情况必定要用生成器？

• 后台管理
• 运维平台
• 配置系统
• 台账系统
• 数据采集平台
• MES / 能源 / 碳排放系统

你目前做的 80% 项目，都适合

---

八、一句“老打工人”的真心话

写 CRUD，
不丢人；
手写 CRUD，才丢人。

若依代码生成器，不是偷懒，
是把精力用在真正值钱的地方。

---

九、最后送你一句话（能用 10 年）

框架不是炫技用的，是帮你活下去的。

会用若依代码生成的人，
不是水平低，
是清醒。