Prettier格式化HTML后乱码本质是编码链路断裂，需统一文件实际编码、编辑器读取、终端环境及HTTP响应头；必须验证真实编码（如PowerShell用Get-Content -Encoding Byte查BOM）、命令行先执行chcp 65001、VS Code保存选UTF-8（不含BOM）、Node.js脚本显式指定utf8读写。
prettier 格式化 HTML 后出现乱码，本质不是格式化工具的问题，而是编码链路断裂：文件实际编码、编辑器读取方式、终端输出环境、HTTP 响应头这四者没对齐。直接改 prettier 配置无效，必须从源头堵漏。
确认 HTML 文件真实编码
VS Code 状态栏右下角显示的编码只是“当前猜测”，不等于文件真实编码。乱码文件常被误标为 UTF-8，实则存为 GBK 或带 BOM 的 UTF-8 with BOM。
- 用命令行验证（Windows PowerShell）：
Get-Content index.html -Encoding Byte | Select -First 3，若输出239 187 191，说明有 UTF-8 BOM（EF BB BF） - Linux/macOS 执行：
file -i index.html，看返回的charset=值 - 用十六进制编辑器（如 HxD）打开，直接看文件头字节
- 若确认是
GBK编码但文件里写了<meta charset="UTF-8">，删掉该标签或重写为<meta charset="GBK">（不推荐，应统一转 UTF-8）
Windows 命令行执行 prettier 必须切代码页
Windows 默认代码页是 936（GBK），prettier 读取/写入时若控制台未设为 UTF-8，会二次转码导致乱码。这不是 bug，是 Windows 控制台的历史包袱。
- 执行
chcp查看当前代码页，非65001则必须先运行：chcp 65001 - 再运行
prettier --write "index.html"，顺序不能反 - PowerShell 中若提示“拒绝访问”，需以管理员身份运行或关闭防病毒软件实时扫描
- 脚本自动化时，务必在命令前加
chcp 65001 >nul &&，避免人工遗漏
VS Code 保存时选错编码选项等于白干
VS Code 的 “Save with Encoding” 菜单里有两个关键区别：UTF-8 和 UTF-8 with BOM。前者是标准 UTF-8，后者开头强制加 EF BB BF —— 这个 BOM 在 HTML 中会破坏 <meta charset> 的优先级判断逻辑。
- 永远选
UTF-8（不含 BOM），不要选UTF-8 with BOM - 设置里关掉
files.autoGuessEncoding，它在混合编码项目中常猜错，反而制造混乱 - 开启
files.encoding为utf8，并确保files.defaultLanguageAssociation对.html关联正确 - 已乱码文件可尝试：Ctrl+Shift+P → “Reopen with Encoding” → 选
GBK→ 再 Ctrl+Shift+P → “Save with Encoding” → 选UTF-8
Node.js 脚本调用 prettier 必须显式指定 encoding
直接用 fs.readFileSync() 读文件，默认按系统编码（Windows 是 GBK）解码，再喂给 prettier.format() 就必然出错。绕过这个陷阱只能靠强制指定。
立即学习“前端免费学习笔记（深入）”；
- 读取时明确声明：
fs.readFileSync("index.html", "utf8") - 写入时也强制：
fs.writeFileSync("index.html", formatted, "utf8") - 不要依赖
prettier.resolveConfig()自动推断编码，它不处理文件 I/O 层 - 批量处理多个文件时，对每个
path单独做fs.readFileSync(..., "utf8")，别用fs.readdirSync()+ 字符串拼接路径后统一读
<meta charset> 去 fallback 系统编码。验证和清理 BOM 应该是排查流程的第一步，而不是最后一步。 
