<meta charset="utf-8">必须置于<head>最开头，因浏览器自上而下解析HTML，若此前已按错误编码（如ISO-8859-1）解码部分字节（如<title>中的中文），将导致乱码且不可逆；声明位置偏移或文件实际编码不匹配UTF-8均会失效。
HTML项目全局编码必须显式声明为 UTF-8，且只能用 <meta charset="utf-8"> 形式，放在 <head> 最开头 —— 其他写法（如 http-equiv）或位置偏移都会导致部分浏览器解析乱码。
为什么 <meta charset="utf-8"> 必须放在 <head> 第一行？
浏览器在解析 HTML 时，会从头开始扫描，一旦遇到第一个 <meta> 声明字符编码的位置，就按该编码解码后续内容。如果它被 <title> 或其他标签挡住，前面已读入的字节可能已被错误解码（比如把中文当 ISO-8859-1 解），造成标题、脚本甚至 CSS 注释里的中文直接显示为 或乱码。
- 实际现象：
<title>用户登录</title>在 Chrome 中显示成 “û¼Ç¼” - 触发条件：该
<meta>出现在<title>后面，或文件本身保存为 GBK 但未声明 - 验证方法：用
curl -I查响应头无charset，再看 HTML 源码中<meta>是否靠前
团队统一设置的三个落地动作
光靠文档约定没用，得让每个成员打开项目就自动生效。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 在项目根目录新建
.editorconfig，强制所有编辑器使用 UTF-8 编码保存：[*]\ncharset = utf-8
- VSCode 项目级配置：在
.vscode/settings.json中写入"files.encoding": "utf8"，避免手动选错 - CI/CD 加一道检查：用
grep -q 'meta charset="utf-8"' index.html验证主入口文件，失败则阻断构建
容易被忽略的兼容性陷阱
即使声明了 UTF-8，仍可能出问题 —— 关键在于“文件实际编码”和“声明编码”是否一致。
立即学习“前端免费学习笔记（深入）”；
- Windows 记事本另存为 UTF-8 时，默认带 BOM，某些旧版 Node.js 工具（如早期 webpack）会把 BOM 当作非法字符报错
- Git 在 Windows 下可能自动转码：设
git config --global core.autocrlf true仅换行符转换，禁用core.safecrlf的编码干预 - 后端模板注入 HTML 片段时（如 PHP 的
include），若片段文件本身是 ANSI 编码，<meta>声明也救不了 —— 必须统一源文件编码
真正卡住团队的往往不是“要不要设”，而是“谁改了文件编码却没同步声明”“新成员用记事本保存覆盖了 UTF-8 文件”。规范要落到编辑器配置和 CI 检查上，而不是只写在 Wiki 里。
