IDEA 生成 Java 实体类：我如何把数据库字段变成可维护代码入口

我以前写这篇文章时，重点是记录一个很具体的小技巧：在 IDEA 里连上数据库，然后根据表字段自动生成 Java 实体类的 get / set 方法。

现在回头看，这件事本身并不大。

但它提醒了我一个长期有用的判断：工程效率不是从少敲几行代码开始的，而是从减少重复、减少手误、减少结构不一致开始的。

实体类看起来只是 Java 项目里最普通的一层。

但如果字段命名、类型映射、注释、空值边界和数据库结构没有对齐，后面写接口、写 ORM、写 DTO、写测试都会一路别扭。

所以我现在更愿意把这类工具用法理解成一件事：先把数据库结构变成可维护的代码入口。

我为什么会关心这个小工具

很多后台项目的第一步，往往不是写复杂业务，而是把数据库里的表映射成代码里的对象。

字段多一点时，手写实体类很容易出现几个问题：

数据库字段和 Java 字段命名不一致；

varchar、datetime、decimal 等类型映射随手写错；

注释丢失，后来的人看不懂字段含义；

get / set 方法漏写或复制错；

后续表结构变更后，代码没有及时同步。

这些错误单独看都不致命，但它们会在项目里慢慢堆成维护成本。

我希望工具帮我处理的不是“打字”本身，而是让结构转换有一个稳定起点。

我的基本流程

我会先在 IDEA 的 Database 面板里连接数据库。

这一步不是为了炫技，而是让 IDE 能真正读到表结构、字段类型、索引和注释。

连接成功后，我会先检查几件事：

数据库环境是不是正确，避免把测试库和生产库看混；

表名是否符合项目当前模块；

字段注释是否足够清楚；

时间、金额、状态、枚举字段是否需要特殊处理；

生成代码的包路径是否符合项目分层。

确认这些之后，再对目标表执行生成脚本或使用 IDEA 自带的数据源能力，把字段转换成 Java 类。

如果项目里已经有 MyBatis Generator、JPA Buddy、MyBatisX 或内部代码生成器，我会优先用项目现成工具。

如果只是一个小项目或临时排查，IDEA 的 Database 能力就足够做第一版实体类。

我会重点检查什么

自动生成之后，我不会直接把文件当成最终答案。

我会先检查字段名。

数据库里常见的 user_name，在 Java 里通常会变成 userName。

这一步看起来简单，但它决定了后面 JSON、ORM、接口文档和前端字段能不能顺畅对齐。

我还会检查类型。

例如：

金额字段我会确认是否需要 BigDecimal；

时间字段我会确认用 LocalDateTime、Date 还是项目既有类型；

状态字段我会判断是否只是 Integer，还是后续要抽成枚举；

长文本字段我会确认是否只是字符串，还是需要单独处理富文本或 JSON。

这些检查比生成本身更重要。

生成器只负责把结构搬过来，工程师要负责判断这个结构能不能长期维护。

get/set 不是重点，边界才是重点

旧文里我主要写的是如何快速生成 get / set。

现在我更在意边界。

如果一个实体类只是数据库表的直接映射，我会让它保持朴素，不往里面塞业务判断。

业务判断放在 service、domain 或项目已经约定的位置。

如果项目使用 Lombok，我也会先看团队习惯。

有些项目倾向 @Data，有些项目会更谨慎地使用 @Getter / @Setter。

我不会为了少写代码就破坏项目风格。

如果实体类会暴露到接口层，我会考虑是否需要 DTO。

数据库实体直接返回给前端，短期省事，长期可能把内部结构暴露得太多。

我的使用地图

以后再遇到类似场景，我会按这个顺序处理：

先确认数据库环境和目标表，不在不确定的数据源上生成代码。

再确认项目已有代码生成方式，优先沿用现有工具链。

生成实体类后，重点检查字段命名、类型映射、注释和包路径。

对金额、时间、状态、枚举、JSON 字段单独检查。

判断实体类是否只做持久化映射，避免把业务逻辑塞进去。

如果要给接口使用，再考虑 DTO、VO 或转换层。

表结构变更后，把实体类同步当成一次小型维护任务，而不是随手覆盖。

这张地图比某个具体按钮更有用。

因为 IDEA、插件和项目框架都会变化，但这些检查点不会很快过时。

这篇旧文现在对我的意义

这篇文章原来是一条工具笔记。

现在我更愿意把它看成一个工程习惯提醒。

当我用 IDEA 从数据库生成 Java 实体类时，我真正想节省的不是几分钟输入时间，而是后面反复对字段、查类型、修低级错误的成本。

工具可以把代码先生成出来。

但代码能不能长期维护，还是要回到结构、命名、边界和复核。

这也是我现在整理旧文时想保留的价值：把一个小技巧放回真实工程流程里，让它不只是“怎么做”，而是“我为什么这样做，以及我会怎样控制它的边界”。