解决html表格中文乱码的关键是确保整页utf-8编码：①必须置于最开头且无bom；②http响应头content-type优先级更高，需服务器正确配置；③css/js等外部资源也须统一为utf-8。
HTML 表格本身不决定字符编码，乱码问题从来不是 <table> 的锅——而是整个 HTML 文档的字符编码没对齐。解决表格中文乱码，本质是让浏览器用 UTF-8 正确解码整页，包括表格里的文字。
<h3>为什么 <code><meta charset="UTF-8"> 必须放在 最开头？
浏览器只扫描 HTML 前 1024 字节来猜编码，如果这范围内没看到 <meta charset="UTF-8">，它就可能 fallback 到系统默认（Windows 常 fallback 到 GBK），导致表格里中文直接变方块或问号。
-
<meta charset="UTF-8">必须是里的第一个标签，前面不能有任何空格、BOM、注释或<script></script> - 常见踩坑：VS Code 默认保存为
UTF-8 with BOM，开头三个字节ef bb bf会挤占扫描空间，让<meta>失效 - 验证方式：
xxd -l 4 index.html（Linux/macOS）或 PowerShell 中Get-Content index.html -Encoding Byte | Select -First 3，输出不该有ef bb bf
HTTP 响应头的 Content-Type 比 <meta> 更优先
当页面通过 HTTP 加载（比如 http://localhost 或线上域名），服务器返回的 Content-Type: text/html; charset=xxx 会直接覆盖 <meta>。如果它写的是 charset=gbk，哪怕你写了十遍 <meta charset="UTF-8">，表格照样乱码。
- 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 请求 →Response Headers查看实际值，确认是text/html; charset=utf-8
外部资源（CSS/JS）也得统一 UTF-8，否则表格样式或脚本会崩
表格依赖的 CSS 文件里如果有中文注释、字体名或提示文字，JS 里有中文字符串或 DOM 文本操作，一旦它们本身是 GBK 编码，浏览器加载时就会报错，连带表格渲染失败。
- 用
file -i style.css（macOS/Linux）或编辑器状态栏确认文件编码是utf-8，不是iso-8859-1或GBK - CSS 文件开头可加
@charset "UTF-8";（必须第一行，前面不能有任何字符） - JS 文件严禁含 BOM；若用
fetch()提交表格数据，记得设请求头：headers: {'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8'} - Vite/Webpack 等构建工具生成的 HTML 模板，也要检查其源文件是否含 BOM —— 构建后 BOM 可能被保留并污染最终 HTML
真正容易被忽略的点：本地双击打开 HTML（file:// 协议）时，没有 HTTP 响应头，全靠 <meta> 和文件编码撑住；此时只要文件带 BOM 或 <meta> 不在前 1024 字节内，表格中文立刻失效。别跳过验证步骤。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
