根本原因是编码链断裂：文件保存编码、声明、HTTP响应头三者不一致或任一缺失；必须闭环验证文件实际编码（UTF-8无BOM）、位于最开头且唯一、服务器响应头Content-Type为text/html; charset=utf-8。
HTML模板中的中文乱码，**根本原因几乎总是编码链断裂**：文件保存编码、<meta charset> 声明、HTTP响应头三者不一致，或其中任一环节缺失。不是“加个标签就完事”，而是必须闭环验证。
检查 HTML 文件实际保存编码（VS Code/Sublime 等编辑器）
很多乱码在保存那一刻就已注定。编辑器显示“中文正常”，不代表文件是 UTF-8 —— 它可能正以 GBK 打开并显示，你保存时仍用 GBK，浏览器却按 UTF-8 解码，结果就是 ä¸æ–‡ 这类字符。
- VS Code：右下角状态栏点击编码名称（如
GBK或UTF-8 with BOM），选Save with Encoding → UTF-8（**不要选 “UTF-8 with BOM”**，BOM 在某些服务器或模板引擎中会引发前置空白或解析异常） - Sublime Text：菜单
File → Save with Encoding → UTF-8 - 用命令行确认是否真为 UTF-8 无 BOM：
head -c 3 filename.html | xxd—— 正常应无ef bb bf输出；若有，说明含 BOM，需另存为纯 UTF-8 - 特别注意：Windows 记事本默认保存为
ANSI（即 GBK），绝不能直接用它改 HTML 模板
确保 <meta charset> 在
这个标签必须出现在 内、且是前 1024 字节内的第一个有效标签。位置错、写法错、重复写，都会让浏览器忽略它。
- 正确写法只有一种：
<meta charset="UTF-8">（注意大小写不敏感，但引号必须，utf8缺少短横线是错的） - 必须放在
<title></title>、<script></script>、<style></style>等任何其他标签之前 - 禁止同时存在多个
<meta charset>，也禁止混用旧式写法<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 两者冲突时浏览器行为不可靠 - Thymeleaf、Jinja2 等模板引擎中，若
<meta charset>被动态插入到非开头位置（比如被包裹在th:fragment里），也会失效
验证 HTTP 响应头中的 Content-Type
本地双击打开 file:// 时，浏览器只看 <meta charset>；但通过 Web 服务器（Nginx/Apache/Tomcat）访问时，**响应头优先级高于 meta 标签**。如果服务器返回 Content-Type: text/html; charset=iso-8859-1，哪怕页面写了 UTF-8，浏览器也大概率按 iso-8859-1 解码。
立即学习“前端免费学习笔记（深入）”；
- Chrome/Firefox：F12 → Network → 刷新页面 → 点击 HTML 请求 → 查看
Response Headers中的Content-Type - Nginx：在
server或location块中加charset utf-8; - Apache：在
.htaccess或虚拟主机配置中加AddDefaultCharset UTF-8 - Tomcat：在
conf/server.xml的Connector中加URIEncoding="UTF-8"和useBodyEncodingForURI="true"（影响 URL 参数，但不改变响应头；响应头需配合 filter 或 response.setCharacterEncoding("UTF-8")）
模板引擎与后端输出的隐性干扰
Thymeleaf、Freemarker、JSP 等模板引擎本身不处理编码，但它们的配置和渲染流程可能覆盖原始设置。
- Thymeleaf：确保
templateResolver.setCharacterEncoding("UTF-8")已设置，且模板文件本身是 UTF-8 编码（见第一条） - Spring Boot：检查
application.properties是否有spring.http.encoding.force=true和spring.http.encoding.charset=UTF-8（对响应头生效） - Java Servlet：在 Controller 或 Filter 中显式调用
response.setCharacterEncoding("UTF-8")，否则 Tomcat 可能按默认 ISO-8859-1 输出 - 数据库读取：若模板中中文来自 MySQL，连接 URL 必须带
?useUnicode=true&characterEncoding=UTF-8，否则查出来就是乱码，再怎么设前端也没用
最容易被忽略的是：**乱码一旦出现在响应体里，就无法靠前端补救**。比如后端把 GBK 编码的字符串直接写进响应流，浏览器拿到的就是错的字节，<meta charset> 再规范也救不回来。所以排查必须从文件保存 → 模板引擎输入 → 后端输出 → HTTP 响应头 → 浏览器解析，逐层向下验证，不能只盯着 HTML 源码改 meta 标签。
