HTML表格中文乱码的根本原因是文档级编码未对齐，需确保文件实际编码、<meta charset="UTF-8">（置于<head>最前且无BOM/注释）、HTTP响应头Content-Type: text/html; charset=UTF-8三者统一，并同步校验JS/CSS等外部资源编码。
HTML 表格本身没有独立的字符编码设置——它完全依赖所在 HTML 文档的整体编码配置。表格里中文乱码，说明文档级编码没对齐，不是 <table> 或 <td> 能单独修复的问题。
meta charset 必须放在 <head> 最开头，且前面不能有 BOM 或注释
浏览器只扫描 HTML 文件前 1024 字节找 <meta charset>，一旦开头有不可见字节或内容，就会跳过它，fallback 到系统默认编码（Windows 常是 GBK）。
- 用命令行检查 BOM：
xxd -l 4 index.html（Linux/macOS）或Get-Content index.html -Encoding Byte | Select -First 3（PowerShell），输出ef bb bf就表示有 UTF-8 BOM，必须删掉 - VS Code 右下角编码显示为 “UTF-8 with BOM” 时，点开 → “Save with Encoding” → 选 “UTF-8”（不含 BOM）
-
<meta charset="UTF-8">必须是<head>内第一个标签，前面不能有<!-- comment -->、<title>、空行或任何字符 - 写法只能是
<meta charset="UTF-8">，不要用<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，后者在 HTML5 中已不推荐
HTTP 响应头 Content-Type 的 charset 优先级高于 meta
当页面通过 HTTP 加载（比如 http:// 或 https://），服务器返回的 Content-Type: text/html; charset=xxx 会直接覆盖 <meta charset>。如果这里写的是 gbk 或缺失 charset，表格里的中文照样乱。
- Nginx 配置需在
http、server或location块中加：charset utf-8;（注意小写，不能写charset=UTF-8） - Apache 在
.htaccess或httpd.conf中写：AddDefaultCharset UTF-8（大小写敏感，不能写utf8） - Express.js 中，在
res.send()或res.render()前调用：res.set('Content-Type', 'text/html; charset=utf-8') - 用 Chrome DevTools 的 Network 标签页，点 HTML 请求 → Headers → Response Headers，确认
Content-Type值是text/html; charset=UTF-8
外部 JS/CSS 文件也得是 UTF-8，否则表格内动态渲染内容仍会乱
如果表格数据来自 <script> 内联脚本、AJAX 或 <link rel="stylesheet"> 里的样式规则，这些文件若保存为 GBK 或含 BOM，浏览器解析时会把中文当非法 token 报错，导致表格渲染中断或文字变方块。
立即学习“前端免费学习笔记（深入）”；
- 用
file -i app.js（macOS/Linux）或编辑器状态栏确认 JS/CSS 文件编码是 UTF-8（无 BOM） - JS 文件开头不要加
@charset "UTF-8";（这是 CSS 用的）；CSS 文件可加，但必须是第一行且无空行/注释：@charset "UTF-8"; - fetch 请求返回 JSON 时，响应头应为
Content-Type: application/json; charset=utf-8；若手动构造请求，headers 中显式设：{'Content-Type': 'application/json; charset=UTF-8'} - 表单提交中文时，
<form accept-charset="UTF-8">可辅助，但现代浏览器默认就是 UTF-8，重点还是后端接收和响应一致
真正容易被忽略的点：本地双击打开 file:// 页面时，没有 HTTP 响应头，全靠 <meta charset> 和文件实际编码撑住——这时 BOM 存在、编辑器误存为 GBK、或 <meta> 被注释挡住，都会让表格第一行中文直接变成 。
