gormt：把 MySQL 表结构变成 Go 结构体，但你要先想清楚这几件事

它解决的问题：手写 struct 的重复劳动

每个用 GORM 的 Go 项目都有一批结构体，字段名、类型、标签要和数据库列一一对应。表一多，手写就变得枯燥且容易出错。gormt 的目标就是让你跑一条命令，把 MySQL 的表变成 Go 的 struct，附带 gorm 标签和 json 标签，还支持大驼峰命名。它面向的是那些已经用 MySQL 做持久化、并且决定用 GORM 作为 ORM 的团队。对于刚起步、还没有固定表结构的项目，这个工具的意义不大，因为你可能还在频繁调整 schema。

工作方式：读取表结构，生成代码，还附带辅助函数

gormt 的核心流程在 README 里写得很清楚：它连接 MySQL，读取表定义，然后按照配置生成 Go 文件。默认输出到 ./model 目录，但你可以通过 config.yml 或命令行参数改。生成的 struct 会包含 gorm 标签，比如 primary_key、unique、index，这些是从数据库的约束推导出来的。它还支持外键关联，比如示例里 UserAccountTbl 结构体里嵌入了 UserInfoTbl，并且用 association_foreignkey 和 foreignkey 标签标明关系。更特别的是，它可以生成辅助函数，比如 FetchByPrimaryKey，这些函数直接调用 GORM 的 API，省去你写重复的查询逻辑。不过要注意，这些函数只是辅助，不是完整的数据访问层，复杂的查询你还是得自己写。

配置项：从 config.yml 到命令行参数，灵活但有点乱

gormt 的配置有两种入口。一种是当前目录下的 config.yml，里面可以设置 out_dir、url_tag、language、db_tag 等。另一种是命令行参数，比如 -H 指定数据库地址，-d 指定数据库名，-p 指定密码。命令行参数可以覆盖配置文件里的值，比如你可以在 config.yml 里设好默认输出目录，然后用 -F=true 临时开启外键导出。README 里有个细节：配置格式以 /data/config/MyIni.go 为准，这暗示文档可能滞后于代码。实际使用时，你会发现有些配置项在 README 里只列了名字，没有解释，比如 is_web_tag_pk_hidden 后面没有说明。这种文档不完整的情况，意味着你得上手试错。

生成代码的质量：标签和注释，但类型映射需要自己扩展

从示例输出看，gormt 生成的 struct 质量不错。字段名是大驼峰，注释直接来自数据库列的 COMMENT，json 标签默认是 snake_case。它还处理了 time.Time 类型，比如 reg_time 字段映射成 time.Time。但类型映射不是万能的，README 提到你可以在 data/view/cnf/def.go 里丰富数据类型。这说明内置的 MySQL 类型到 Go 类型的映射表是有限的，遇到不常见的类型（比如 geometry 或者自定义枚举）你可能得自己改源码。另外，is_null_to_point 选项可以把 DEFAULT NULL 的字段映射为指针类型，这有助于区分零值和 NULL，但默认是关闭的，你需要主动开启。

GUI 和命令行：两种模式，但 GUI 看起来是附属品

gormt 支持 GUI 模式，运行 ./gormt -g=true 就能打开图形界面。README 提供了一个 Windows 下的 GUI 下载链接，但那是 v0.3.8 的版本，明显比 v2.1.gorm 旧。这说明 GUI 可能不是主要维护方向。命令行模式才是核心，适合集成到 CI 或本地脚本里。对于大多数开发者，命令行模式更实用，因为你可以把生成步骤写进 Makefile 或 pre-commit 钩子。但如果你不熟悉命令行，GUI 可以让你可视化地选择表和配置，不过你得接受它可能缺少最新功能。

限制和失败模式：外键依赖、Windows 编码、以及项目停滞

gormt 有几个明显的坑。第一，外键导出依赖表之间的外键约束，如果数据库没有定义外键，is_foreign_key 选项就没效果。第二，Windows 下不支持 UTF-8 风格，README 特别提示要用 CHCP 65001 切换编码，否则生成的代码可能乱码。第三，项目自 2021 年 6 月后没有新提交，v2.1.gorm 是最后一个 release。这意味着它不支持更新的 GORM 版本可能带来的变化，比如 GORM v2 的标签写法如果有调整，gormt 可能跟不上。另外，生成代码里包含 GetTableName 函数，但默认 is_table_name 是 false，你需要显式开启，否则某些辅助函数可能依赖的表名方法不存在。

替代方案：xo 和 sqlboiler 的差异

如果你觉得 gormt 不够用，可以考虑 xo 或 sqlboiler。xo 是一个更通用的数据库转 Go 工具，支持多种数据库，不只是 MySQL，而且它生成代码的方式是基于模板，你可以自定义输出格式。sqlboiler 则专注于生成完整的数据访问层，它生成的代码是类型安全的，查询构建器比 GORM 更严格。与 gormt 相比，xo 和 sqlboiler 都更活跃，社区更大，文档也更完整。但它们的输出不直接绑定 GORM，如果你已经用了 GORM，可能需要额外适配。gormt 的优势是它专门为 GORM 设计，生成的标签和辅助函数与 GORM 的 API 直接对应，省去适配工作。

维护成本：一次生成，但后续要手动合并

gormt 生成的代码是静态的，不会自动同步数据库变更。这意味着你每次修改表结构，都得重新运行 gormt，然后把新生成的代码合并到现有项目里。如果项目里已经有人手写修改过生成的结构体，合并时就会冲突。这是所有代码生成工具的通病，但 gormt 没有提供增量更新的机制。另外，生成的辅助函数是完整的代码，不是接口，所以你不能覆盖它们，只能修改生成的文件。这增加了维护成本。许可证是 MIT，你可以自由修改和分发，但如果你改动了源码，就得自己维护 fork。

编辑结论

gormt 适合那些表结构相对稳定、需要快速生成 gorm 模型和基础 CRUD 辅助函数的 Go 后端项目。如果你已经用了 GORM 的 AutoMigrate 或者习惯手写结构体，它反而会引入额外的生成步骤和代码风格约束。不适合用它来应对频繁变动的表结构，因为每次改表都要重新生成并合并代码，容易产生冲突。在决定采用之前，先确认你的 MySQL 版本和字符集是否兼容，尤其是 Windows 下 UTF-8 支持问题。然后跑一次生成，检查生成的标签是否符合你团队的 gorm 用法，比如是否使用 singular 表名、是否要导出外键。最后，注意项目自 2021 年 6 月后没有新提交，v2.1.gorm 是最后一个版本，这意味着你遇到 bug 时可能得不到及时修复。如果你能接受自己改源码或 fork，那么 gormt 的 MIT 许可允许你这么做。否则，考虑使用 xo 或 sqlboiler 这类仍在维护的工具，它们处理数据库类型映射的方式更灵活。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes