Mac版Navicat导出JSON默认UTF-8无BOM，而Windows工具依赖BOM或回退GBK解码，导致乱码；其根本原因是Navicat JSON导出无编码选项，固定不写BOM，且消费端解码逻辑跨平台不一致。
Mac版Navicat导出JSON文件与Windows系统编码不一致，根本原因不是“跨平台默认不同”，而是Mac版Navicat在导出JSON时**根本不写BOM头，且不声明编码**，而Windows端工具（尤其是Excel、记事本、老旧编辑器）依赖BOM或默认回退到GBK/ANSI，导致同一文件在两端打开显示迥异。
导出JSON时Navicat根本不控制BOM，Windows却靠它猜编码
Navicat所有版本（含macOS v17.0+）导出JSON格式时，编码选项完全不可见——它固定以UTF-8无BOM方式写入文件。这和CSV导出不同，CSV有明确的「编码」下拉菜单，JSON没有。结果就是：Mac上导出的data.json开头字节是e6 9d ad（“杭”的UTF-8编码），而非ef bb bf（UTF-8 BOM）。Windows记事本看到没BOM，就按当前区域设置（如中文Windows默认GBK）解码，直接把UTF-8字节当GBK解析，出现“浣犲ソ”类乱码。
JSON文件本身无需BOM，但消费端行为差异极大
严格来说，RFC 7159规定JSON文本默认为UTF-8，且**不强制要求BOM**。问题出在实际工具上：
- macOS Numbers / VS Code / Chrome DevTools：直接按UTF-8解码，无视BOM，所以Mac导出的JSON在Mac上总能正常显示
- Windows记事本 / Excel 2019及更早版 / 某些Python脚本（未显式指定encoding）：看到无BOM UTF-8，就 fallback 到系统ANSI（如GBK），必然乱码
- Sublime Text / Notepad++：能自动探测UTF-8，但需关闭“猜测编码”才稳定
这不是Navicat“做错了”，而是它把编码责任完全交给了下游工具——而下游工具在Windows上更不靠谱。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
真正可控的修复动作只有两个
别指望改Navicat设置（它没这个选项），直接操作文件或流程：
- 导出后立刻用终端加BOM：
sed -i '' '1s/^/\xef\xbb\xbf/' data.json（macOS sed语法）；Linux用sed -i '1s/^/\xef\xbb\xbf/' data.json - 导入前在Windows端用Notepad++打开 → 编码 → 转为UTF-8-BOM → 保存；或用VS Code右下角点击编码 → 选择“Save with Encoding” → “UTF-8 with BOM”
- 若用Python读取，必须显式声明：
json.load(open("data.json", encoding="utf-8"))，不能依赖open()默认编码
比编码更隐蔽的问题：换行符与空格
Mac导出JSON默认用\n换行，Windows习惯\r\n。虽然JSON标准允许任意空白，但某些旧版解析器（如IE11 JSON.parse、部分嵌入式JSON库）会把\r误认为字段内容。同时，Navicat导出JSON时默认开启「每行一条记录」，但若勾选了「使用双引号包裹字段名」却漏掉该选项，会导致输出为单行超长字符串——这种文件在Windows资源管理器里右键预览常直接卡死或截断。验证方式很简单：head -c 20 data.json | hexdump -C看开头是否含BOM，file data.json看报告的line endings。
