<meta charset="UTF-8">必须放在<head>最开头、<title>之前，写法唯一标准，且文件需保存为无BOM的UTF-8编码，同时HTTP响应头charset须与之一致。
HTML文件里该放哪、怎么写
必须放在 <head> 的最开头，紧贴 <head> 开始标签之后，且在 <title> 之前。浏览器解析到它时会立即切换编码，晚了就可能已按错误编码读入部分字符，导致乱码无法挽回。
写法只接受一种标准形式：<meta charset="UTF-8">。不能加斜杠闭合（<meta charset="UTF-8"/> 是错的），不能用单引号，不能写成 utf8、utf_8、UTF8 或 utf-8 —— IETF 规范明确定义为 UTF-8（大写 U、T、F，短横，大写 8）。
- 错误示例：
<meta charset='utf-8'>、<meta http-equiv="Content-Type" content="text/html; charset=utf-8">、<meta charset="utf8"> - 正确位置示意：
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>页面标题</title> ...
编辑器保存格式和文件BOM必须匹配
VS Code、Sublime Text 等编辑器保存 HTML 文件时，需手动确认编码格式是 UTF-8，且**不带 BOM**。带 BOM 的 UTF-8 with BOM 会在文件开头插入不可见字节（EF BB BF），IE 和某些 WebView 会把它当乱码渲染，甚至让 <meta charset> 失效。
常见现象：页面局部中文显示为方块、emoji 显示异常、控制台报“Invalid character”、git diff 出现无意义变更。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- VS Code：右下角状态栏点击编码名 → 选
Save with Encoding→ 选UTF-8（不是UTF-8 with BOM） - Sublime Text：菜单
File → Save with Encoding → UTF-8 - Notepad++：菜单
编码 → 转为 UTF-8 编码（勿选“UTF-8-BOM”）
HTTP响应头里的charset别和打架
Web 服务器（如 Nginx、Apache）返回 HTML 时，若 HTTP 响应头中 Content-Type 字段也指定了 charset（例如 Content-Type: text/html; charset=GBK），它会**优先于** <meta charset> 生效。两者不一致就会强制浏览器用错编码，再规范的 <meta> 也救不回来。
排查方法：打开 Chrome DevTools → Network → 找 HTML 请求 → 查看 Response Headers 中的 Content-Type 值。
- Nginx 配置应含：
charset utf-8;（注意小写 utf-8，这是 Nginx 写法，与 HTML 中的UTF-8不冲突） - Apache 配置应含：
AddDefaultCharset UTF-8或在.htaccess中加此行 - 本地开发用 vite / webpack serve 通常默认发
UTF-8，但若用了自定义中间件或代理，需检查是否被覆盖
团队协作时最容易忽略的三个点
统一编码不是写对一行 <meta charset="UTF-8"> 就完事。真正出问题的地方往往藏在工具链和人习惯里：
- 新成员拉代码后直接新建 HTML 文件，编辑器默认用系统编码（如 Windows 的 GBK）保存，
<meta>写得再对也没用 - 后端模板引擎（如 EJS、Thymeleaf）渲染时未设置输出编码，生成的 HTML 文件实际是 GBK，前端只改
<meta>属于掩耳盗铃 - 构建工具（如 Webpack + html-webpack-plugin）若配置了
minify: { removeComments: true }，可能误删<meta charset>—— 必须显式保留或禁用该插件的自动删除逻辑
