html是唯一能跨平台保持结构、可读性与功能一致的导出格式，因pdf无超链接且不可复制字段名，excel会错位丢失外键索引且不保留comment；导出时须手动选utf-8编码并用本地服务器打开以确保js/css正常运行。
HTML 是唯一能跨平台保持结构、可读性与功能一致的导出格式，其他格式在字体渲染、编码处理或交互能力上必然出现偏差。
为什么不能选 PDF 或 Excel 导出数据字典
PDF 看起来“正式”，但 Navicat 导出的 PDF 实际是静态快照：没有超链接跳转（点不了表名跳到字段列表）、无法复制字段名（中文常粘连成块）、搜索功能受限（尤其带标点的字段名搜不到）。Excel 更糟——它会把“表名”“字段名”“类型”“注释”强行压进单行，遇到长注释直接换行错位，外键关系、索引顺序全丢失。Mac 上用 Numbers 打开可能列宽归零，Linux 用 LibreOffice Calc 打开时 UTF-8 中文偶尔显示为方块，这些都不是设置问题，而是导出逻辑本身没做跨平台适配。
- PDF 导出路径：
工具 → 数据库字典 → 导出 → PDF，但生成后无法右键复制user_id这类字段名 - Excel 导出不保留
COMMENT内容，MySQL 的列注释字段在 Excel 表格里直接为空 - Windows 和 macOS 对 PDF 字体嵌入策略不同，同一份导出文件在两台机器上打开，中文字体渲染可能一个清晰一个模糊
HTML 格式必须手动指定 UTF-8 编码
Navicat 默认导出 HTML 时，编码下拉框常预设为 System 或 GBK，尤其 Windows 安装包默认继承系统编码。这会导致 Mac/Linux 用户双击打开 HTML 文件时，中文全变成问号或乱码——不是浏览器问题，是文件头声明的 charset 和实际内容不匹配。
- 导出前务必点击导出对话框底部的“编码”下拉框，手动选
UTF-8 - 检查连接属性里的字符集是否为
utf8mb4（MySQL）或UTF8（PostgreSQL），否则即使导出选了 UTF-8，源数据本身已乱码 - 导出后用文本编辑器打开 HTML 文件，搜索
<meta charset="</code">，确认值是 <code>"UTF-8"（注意大小写和引号）
跨平台打开 HTML 字典的正确姿势
直接双击 HTML 文件在 Chrome/Firefox/Safari 里打开，看似方便，实则高危：Chrome 从 v110 起禁用本地 file:// 协议下的部分 JS 功能，导致 Navicat 生成的搜索框、目录跳转、折叠面板全部失效；Safari 在 macOS 上对本地 HTML 的 CSS 加载更保守，表格边框可能消失。
- Mac/Linux 用户应启动轻量本地服务器：
python3 -m http.server 8000，然后访问http://localhost:8000/xxx.html - Windows 用户可用 PowerShell 启动：
http-server -p 8000（需先npm install -g http-server），避免 Edge 对 file:// 的兼容限制 - 所有平台都别依赖“打印预览”功能——它只是浏览器渲染快照，导出 PDF 后又回到前面说的不可复制、无跳转的老问题
真正跨平台一致的关键不在“怎么导”，而在“导什么”：Navicat 不会自动抓取 Oracle 的 ALL_TAB_COMMENTS 里缺失的列级注释，也不会识别 SQL Server 中未用 sp_addextendedproperty 显式绑定的字段描述。这些底层差异，比 Win/Mac/Linux 的字体渲染更难抹平。
