必须用「查询结果→导出结果→HTML」路径，不能右键表直接导出；否则导出全表、不支持WHERE过滤、中文注释丢失。需先执行带WHERE的SELECT语句（如SELECT id,name,status,created_at FROM orders WHERE status='shipped' AND created_at>='2024-01-01'），再通过「文件→导出结果」导出，并在导出设置中手动选UTF-8编码，否则中文乱码。
必须用「查询结果→导出结果→HTML」路径，不能右键表直接导出数据；否则导出的是全表（含无用字段）、不支持 WHERE 过滤、中文注释丢失。
导出前必须先写好带 WHERE 的 SQL 查询
Navicat 的 HTML 导出本质是把当前结果集渲染成表格，不是对表结构做快照。如果跳过 SQL 直接右键表→导出向导→导出数据，会导出整张表所有字段和所有行，无法控制范围。
- 执行
SELECT id, name, status, created_at FROM orders WHERE status = 'shipped' AND created_at >= '2024-01-01'，再点「文件→导出结果」 - 避免用
SELECT *：字段顺序不可控，导出后列名可能错位；字段过多时 HTML 文件体积暴涨，浏览器卡死 - MySQL 日期用
'2024-01-01'，PostgreSQL 建议加AT TIME ZONE 'UTC'，否则导出时间值可能偏差
导出设置里必须手动选 UTF-8 编码
Navicat 默认用系统 locale（如 Windows-1252）编码生成 HTML，中文字段名、注释、内容全变成方块或问号——这不是浏览器问题，是文件本身编码错了。
- 在导出向导第三步（“导出设置”页），找到「编码」下拉框 → 手动选
UTF-8（别信默认值） - 导出后用记事本或 VS Code 打开 HTML 文件，搜索
<meta charset=，确认值为"UTF-8"；如果不是，说明这一步没生效 - 若仍乱码，回溯检查连接层字符集：右键连接→编辑连接→高级→字符集设为
utf8mb4（MySQL）或UTF8（PostgreSQL）
导出的 HTML 在 Chrome/Edge 里打不开？关掉 file:// 协议限制
Navicat 生成的 HTML 含内联 JavaScript（用于折叠、高亮、排序），Chrome 和 Edge 默认禁止 file:// 协议下执行脚本，导致白屏、只显示标题栏、搜索框失效。
立即学习“前端免费学习笔记（深入）”；
- 双击打开失败时，不要反复重试——直接拖进 Firefox 打开，它允许本地脚本执行
- 想用 Chrome 查看：启动 Chrome 时加参数
--unsafely-treat-insecure-origin-as-secure="file:///" --user-data-dir=/tmp/chrome-test（仅临时调试） - 更稳做法：用 Python 起个本地服务，
python3 -m http.server 8000，然后访问http://localhost:8000/output.html
字段类型显示不全？真实类型藏在 title 属性里
Navicat 导出的 HTML 表格中，“数据类型”列常简写为 VARCHAR，但实际定义如 TINYINT(1)、DATETIME 全部存在对应 <td title="TINYINT(1)"> 的 title 属性中。直接浏览器查看看不到，复制到 Markdown 或 Excel 时就丢光了。
- 人工查阅时，鼠标悬停在类型单元格上，就能看到完整定义
- 需要自动化提取（比如转 Markdown）：别用正则硬匹配
title="..."，改用BeautifulSoup解析，调用td.get('title') or td.get_text(strip=True) - 导出前可先运行一条测试查询：
SELECT COLUMN_NAME, COLUMN_TYPE, COLUMN_COMMENT FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'your_table'，确认元数据本身有值
真正麻烦的不是操作步骤，而是每个环节都依赖上一环的编码、权限、SQL 写法是否干净——少校验一处，导出的 HTML 就是废文件。尤其是跨团队交付时，前端或测试拿到一个白屏或乱码 HTML，基本不会回头查 Navicat 设置，只会认定“这个文档不可用”。
