Beego 不提供数据库字典生成工具，需自行结合 information_schema 查询、Go 模板渲染实现；bee generate scaffold 仅生成基础代码，忽略字段注释、索引、外键等关键语义信息。
Beego 本身不提供数据库字典（data dictionary）生成工具，也没有内置命令能直接导出表结构说明、字段注释、索引关系等文档。所谓“自动化生成数据库字典”，需要你自行组合 bee generate + 数据库元信息查询 + 模板渲染来实现，不能靠一条命令解决。
beego 的 generate scaffold 只生成代码，不生成字典
bee generate scaffold 的作用是根据数据库表反向生成 model、controller、router 和视图文件，它读取的是表名和字段基础类型（如 string、int），但会忽略：
– 字段 COMMENT
– 索引定义（UNIQUE / FULLTEXT / 复合索引）
– 外键约束（FOREIGN KEY 关系）
– 默认值（DEFAULT）
– 是否允许 NULL
– 字符集与排序规则（CHARSET/COLLATE）
也就是说，它生成的 models/*.go 文件里只有结构体字段和 orm:"column(xxx)" 标签，没有业务含义描述——而这恰恰是数据库字典的核心。
常见误操作：
– 以为运行一次 bee generate scaffold -conn="..." -driver=mysql 就自动生成了可交付的字典文档
– 把生成的 Go struct 当作数据字典使用，结果字段含义、长度限制、枚举范围全靠猜
手动查 MySQL 元数据表是唯一可靠起点
要拿到完整字段语义，必须直连数据库，查 information_schema。例如获取某张表的带注释字段清单：
SELECT COLUMN_NAME AS field, DATA_TYPE AS type, IS_NULLABLE AS nullable, COLUMN_DEFAULT AS default_value, COLUMN_COMMENT AS comment, CHARACTER_MAXIMUM_LENGTH AS max_length, NUMERIC_PRECISION AS precision, NUMERIC_SCALE AS scale FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_db_name' AND TABLE_NAME = 'user' ORDER BY ORDINAL_POSITION;
注意几个关键点：
– COLUMN_COMMENT 是你写在建表语句里的 COMMENT '用户昵称'，这是字典里最不能丢的信息
– IS_NULLABLE 要转成 “是”/“否”，不能只留 YES/NO
– DATA_TYPE 需映射为 Beego ORM 支持的类型（比如 tinyint(1) → bool，datetime → time.Time）
– 如果表用了外键，还得额外查 KEY_COLUMN_USAGE 表补上关联目标
用 Go 模板 + database/sql 快速拼出 HTML/Markdown 字典
不需要重造轮子，写一个 50 行左右的独立小工具即可。核心逻辑：
– 用 database/sql 连接 MySQL，执行上面的元数据查询
– 把结果 scan 到结构体切片（如 type ColumnInfo struct { Field, Type, Comment string }）
– 加载 Go text/template，填入数据，输出 HTML 或 Markdown
示例模板片段（HTML）：
{{range .Columns}}<tr>
<td>{{.Field}}</td>
<td>{{.Type}}</td>
<td>{{.Comment}}</td>
<td>{{.Nullable}}</td>
</tr>
{{end}}
运行时传参控制范围：
– -db=beegotest 指定库名
– -tables=user,order,product 指定表列表（支持通配符或正则）
– -format=md 输出 Markdown，-format=html 输出 HTML
– -output=docs/dict.md 指定保存路径
这个脚本可以放在项目根目录下，加进 Makefile 或 scripts/，每次上线前跑一次，比人工维护靠谱得多。
别指望 Swagger 文档替代数据库字典
Beego 配合 Swagger（通过 bee run -gendoc=true）能生成 API 接口文档，但它只反映 controller 层接收/返回的结构体，和底层数据库表不是一一映射关系：
– 一个 API 返回的 struct 可能 join 多张表，字段来自不同来源
– model 里被 orm:"-" 忽略的字段不会出现在 Swagger 中
– 字段注释（// 用户手机号）虽能被提取，但无法体现数据库级约束（如唯一索引、CHECK）
所以：Swagger 是接口契约，不是数据契约。数据库字典必须从 information_schema 出发，绕不开。
真正容易被忽略的点：字段 COMMENT 在 MySQL 里默认是空字符串，不是 NULL；很多团队建表时不写 COMMENT，导致生成的字典全是空白栏——这时候得倒逼 DBA 或后端在 DDL 里补全，而不是靠工具“智能猜测”。
