导出数据字典应优先使用pg_dump -s或mysqldump -d获取纯净ddl，再用sqlparse解析生成结构化字段列表，手动拼html并显式控制列宽与中文字体，注释需strip归一化处理。
用 pg_dump 或 mysqldump 提取表结构，别碰数据
导出数据字典的第一步不是写脚本，而是让数据库自己吐出干净的 ddl。直接连库查 information_schema 容易漏约束、默认值、注释，还可能因权限或版本差异翻车。
实操建议：
-
pg_dump -s -U user db_name > schema.sql（PostgreSQL，-s表示只导结构） -
mysqldump -d -u user -p db_name > schema.sql（MySQL，-d等价于--no-data） - 加
--skip-comments避免导出时混入连接信息或时间戳注释 - 如果要保留字段注释，PostgreSQL 需额外执行
pg_dump --schema-only --inserts --column-inserts不行，得用pg_dump -s -E utf8 --no-owner --no-privileges再配合COMMENT ON COLUMN手动补——这点常被忽略
用 sqlparse 解析 SQL 生成结构化字段列表
原始 schema.sql 是给人看的，机器难读。硬正则匹配 CREATE TABLE 和括号内容极不可靠，尤其遇到嵌套括号、多行注释、反引号包裹名时必崩。
实操建议：
- Python 用
sqlparse库解析：它能正确识别语句边界和 token 类型，比手写正则稳得多 - 重点提取
IdentifierList（字段名）、Function（如jsonb类型）、Comment（紧跟字段后的--或/* */注释） - 注意 MySQL 的
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4是表级属性，别误判成字段类型 - PostgreSQL 的
GENERATED ALWAYS AS (...) STORED是计算列，需单独标记，不能当普通字段处理
生成 HTML 时用 table + colgroup 控制列宽，PDF 转换才不挤
用 pandas.DataFrame.to_html() 直接输出表格看着快，但生成的 HTML 缺少语义化列定义，weasyprint 或 wkhtmltopdf 渲染 PDF 时列宽乱跳，尤其字段名长、类型短的组合下，类型列会被压成“...”。
实操建议：
- 手动拼 HTML，用
<colgroup> <col width="20%"> <col width="15%"> </colgroup>显式控制每列宽度 - 字段名列加
white-space: nowrap，类型列允许换行，避免单行撑爆整页 - PDF 中中文字体必须显式指定，
weasyprint默认不认系统字体，得在 CSS 里写@font-face引入Noto Sans CJK SC或本地simhei.ttf - 别用
border-collapse: collapse配合细边框——PDF 渲染器对 subpixel 边框支持差，容易出现断线或虚影
字段注释为空时，COMMENT 不等于 NULL，也未必是空字符串
很多数据库导出的字段注释字段是 NULL，但有些 ORM 或管理工具会把它转成空字符串甚至 " "（带空格）。直接 if not comment: 判空会把后者当成有注释，结果文档里冒出一堆空白格子。
实操建议：
- 统一用
comment.strip() if comment else ""归一化处理 - PostgreSQL 的
obj_description()函数返回NULL表示无注释；MySQL 的COLUMN_COMMENT字段类型是TEXT，空注释就是空字符串，两者行为不一致 - 如果上游没开注释，别自动填“暂无”，更别填“未填写”——这属于元数据污染，后续有人真写了注释反而难区分真假
字段注释的来源链路太长：建表时写、后期用 COMMENT ON 加、ORM 迁移脚本带、DBA 手动补……任何一个环节掉链子，字典就缺一块。别指望一次导出全对，得留个校验入口，比如按表名比对 pg_tables 和实际解析出的表数量。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
