html乱码主因是字符编码未闭环一致：须置于最开头（前1024字节内，无bom/空格/注释），文件本身须存为utf-8无bom；http响应头content-type: text/html; charset=utf-8优先级更高，需服务器（nginx/apache/express）正确配置；js/css/json等关联资源也须统一utf-8编码。
HTML 表格本身不设置字符编码，乱码问题从来不是 <table> 的锅——它只是容器。真正决定中文能否正确显示的，是整个 HTML 文档的字符编码配置是否闭环一致。<h3>为什么 <code><meta charset="UTF-8"> 必须放在 最开头
浏览器只扫描 HTML 文件前 1024 字节来查找 <meta charset>，一旦错过就 fallback 到系统默认（Windows 是 GBK，Linux/macOS 常是 ISO-8859-1），表格里的中文立刻变方块或问号。
- 必须紧贴
开始，前面不能有任何字符：包括空格、换行、BOM（ef bb bf）、HTML 注释<!-- -->、<title></title>或<script></script> - VS Code 默认保存为 “UTF-8 with BOM”，要手动选 “Save with Encoding” → “UTF-8”（不含 BOM）
- 用命令验证：Linux/macOS 运行
xxd -l 4 index.html，输出不含ef bb bf才安全；PowerShell 用Get-Content index.html -Encoding Byte | Select -First 3
HTTP 响应头 Content-Type 和 <meta> 谁说了算
当页面通过 HTTP 加载（http:// 或 https://），服务器返回的响应头 Content-Type: text/html; charset=utf-8 优先级高于 <meta charset>；但如果响应头没带 charset（比如 Nginx 默认不配），浏览器才退而求其次看 <meta>。
- Nginx 配置需在
http、server或location块里加：charset utf-8;（注意小写，不能写charset=UTF-8） - Apache 在
.htaccess或配置文件中写：AddDefaultCharset UTF-8（大小写敏感，不能写utf8） - Express.js 中，
res.set('Content-Type', 'text/html; charset=utf-8')必须在res.send()或res.render()之前调用 - 用 Chrome DevTools 的 Network 标签页刷新页面，点 HTML 请求 → Headers → Response Headers，确认
Content-Type值含charset=utf-8
表格数据来自外部时，JS/CSS/JSON 也得统一 UTF-8
表格内容若由 JS 动态插入（比如 fetch() 拉 JSON）、或 CSS 控制样式（比如注释含中文）、或内联 <script></script> 写死数据，这些文件自身的编码不匹配，照样触发乱码甚至语法错误。
-
Uncaught SyntaxError: Invalid or unexpected token很可能是因为.js文件实际是 GBK 编码，但被浏览器当 UTF-8 解析 - 用
file -i app.js（macOS/Linux）或编辑器状态栏确认 JS/CSS 文件编码为 UTF-8（无 BOM） - JSON 接口返回时，响应头也应设
Content-Type: application/json; charset=utf-8；前端fetch()不用额外处理，但XMLHttpRequest可能需要手动设请求头 - 避免在
<style></style>或<script></script>标签内写中文注释或字符串，除非 100% 确认 HTML 文件和这些内联块都走 UTF-8
最易被忽略的其实是本地双击打开的 file:// 场景：没有 HTTP 响应头，全靠 <meta charset>，此时 BOM 和位置错误会直接暴露；而生产环境哪怕配置对了 HTML，只要一个 AJAX 返回的 JSON 是 GBK，表格某列照样炸开。闭环不在单点，而在所有环节的编码声明与文件实际编码严格咬合。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
