必须放在最开头，因为浏览器仅扫描前1024字节查找该标签，若开头存在bom、注释、空行或等干扰，会导致fallback至系统默认编码（如windows的gbk），引发乱码及脚本错误。
HTML 表格本身不决定字符编码，乱码根源在整页的编码配置没对齐。只要页面级编码设置正确，<table> 里的中文自然能正常显示。<h3>为什么 <code><meta charset="UTF-8"> 必须放在 最开头？
浏览器只扫描 HTML 前 1024 字节来查找 <meta charset>，一旦开头有干扰，就直接 fallback 到系统默认（Windows 是 GBK）。
- BOM 字节（
ef bb bf）会卡在文件最前面，让<meta>实际位置超出前 1024 字节 -
<!-- 注释 -->、空行、<script></script>或<link>标签写在<meta>前，也会挤占有效扫描空间 - VS Code 默认保存为 “UTF-8 with BOM”，必须手动选 “UTF-8”（无 BOM）再保存
- 验证方式：
xxd -l 4 index.html，输出不含ef bb bf才算干净
HTTP 响应头里的 Content-Type 和 <meta> 谁说了算？
HTTP 响应头里的 Content-Type: text/html; charset=utf-8 优先级高于 <meta charset>；但若响应头没带 charset（比如 Nginx 默认不设），浏览器才退而求其次看 <meta>。
- Nginx 配置要写成
charset utf-8;（小写，末尾分号不能少），加在http、server或location块里 - Apache 用
AddDefaultCharset UTF-8（注意大小写，不是utf8） - Express.js 中要在
res.send()前调用res.set('Content-Type', 'text/html; charset=utf-8') - 本地双击打开（
file://协议）时没有 HTTP 头，<meta>是唯一救命稻草，此时 BOM 尤其致命
外部 JS/CSS 文件的编码也得统一为 UTF-8（无 BOM）
表格里如果用 JS 动态生成内容，或 CSS 控制样式（比如含中文的 ::before 伪元素），这些文件若存为 GBK 或带 BOM 的 UTF-8，一样会触发 Uncaught SyntaxError: Invalid or unexpected token。
- 用
file -i app.js（macOS/Linux）或 PowerShell 的Get-Content app.js -Encoding Byte | Select -First 3检查是否含 BOM - JS 文件里不需要写
@charset；CSS 文件第一行可加@charset "UTF-8";，但仅当文件实际是 UTF-8 且无 BOM 时才生效 - Vite/Webpack 等构建工具默认处理 UTF-8，但自定义 HTML 模板（如
index.html）仍可能被编辑器偷偷加 BOM
真正容易被忽略的是：表格单元格里嵌了 <script></script> 或 <style></style> 标签，或者用了服务端模板（EJS、Pug），这些地方的编码独立于主 HTML，得单独确认。BOM 只要出现在任意一个参与渲染的文本文件开头，就会让整块中文垮掉。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
