GORM本身不生成E-R图，需借助外部工具：推荐PostgreSQL场景用go-planter（直连数据库解析外键规则生成PlantUML），MySQL+若依项目可用ruoyi-er（粘贴GORM建表SQL解析）。
GORM 本身不生成 E-R 图，必须借助外部工具解析 Go 模型或数据库结构来生成。直接用 GORM 的 struct 标签或迁移代码，无法导出图形；真正能落地的方案，是「从数据库反向生成」或「从 GORM 模型源码解析生成」，且需工具明确支持 GORM 标签语义（如 foreignKey、many2many、polymorphic）。
推荐用 Go-planter：专为 PostgreSQL + GORM 场景设计
Go-planter 是目前少有明确适配 GORM 生态的开源 CLI 工具，它不依赖 Go 源码，而是直连 PostgreSQL 数据库，读取 pg_class、pg_constraint 和 GORM 习惯使用的外键命名规则（如 user_id → 关联 users 表），生成 PlantUML 文本。
- 它能识别 GORM 的
HasOne/HasMany外键字段，并标注基数（1..1、1..*） - 输出是纯文本
.puml文件，可用 PlantUML Server 或 VS Code 插件实时预览/导出 PNG/SVG - 不上传数据到任何服务器，适合敏感项目；但仅支持 PostgreSQL，MySQL 需额外适配（暂无官方支持）
- 典型命令：
go-planter -host=localhost -port=5432 -dbname=myapp -user=postgres -password=xxx -output=er.puml
若依（RuoYi）集成版：适合已有若依 + MySQL + GORM 混合栈
若依社区版已整合 SQL 转 ER 图功能（ruoyi-er），虽非原生 GORM 工具，但它支持将 GORM 生成的建表 SQL（即 db.AutoMigrate() 实际执行的 DDL）粘贴进去，再解析外键约束与主键关系。
- 优势在于能处理 GORM
TableName()自定义表名、gorm.Model基础结构、软删除字段（deleted_at）等常见扩展 - 不依赖数据库连接，纯 SQL 字符串输入，适合 CI/CD 中生成文档阶段使用
- 注意：若 SQL 中用了 GORM 的
columnType自定义类型（如 JSON 字段映射为jsonb），需手动补全注释说明，否则关系识别可能遗漏
避坑重点：别误信“GORM 模型文件直出 ER 图”的工具
很多工具声称支持 “Go struct to ERD”，但实际只做字段名→属性的简单映射，完全忽略 GORM 的关联逻辑：
-
foreignKey:"author_id"不会被识别为外键，而当作普通字符串字段 -
many2many:"article_tags"关系表会被当成独立实体，而非连接关系 - 嵌套结构体（如
Address内嵌在User中）常被错误渲染为 1:1 关联，而非组合关系 - 真正可靠的路径只有两条：走数据库元信息（最准），或用 AST 解析器深度读取 Go 源码+标签（开发成本高，目前无成熟开源实现）
如果你的项目已上线且数据库稳定，优先跑一次 go-planter；如果还在开发早期、用 MySQL、又重度依赖若依脚手架，ruoyi-er 的 SQL 粘贴模式更轻量。所有工具都绕不开一个事实：GORM 的关系语义藏在运行时和标签里，静态分析永远有盲区——图只是辅助，关键关联逻辑仍要核对代码中的 Preload 和 Joins 调用。
