必须置于最前面，因浏览器仅扫描前1024字节查找该声明；若被、注释、bom或空行遮挡，将回退至系统默认编码（如windows的gbk），导致表格内中文显示乱码。
<table> 标签本身不处理字符编码，中文乱码不是表格导致的，而是整个 HTML 文档的编码链没对齐。只要文档整体 UTF-8 正确，<code><table> 里的中文自然就正常。<h3>为什么 <code><meta charset="UTF-8"> 必须放在 最前面
浏览器解析 HTML 时，只扫描前 1024 字节来查找 <meta charset>。如果它被 <title></title>、注释、BOM 或空行挡在后面，就会 fallback 到系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1），导致 <td>你好</td> 显示成 。
-
<meta charset="UTF-8"> <title>...</title>✅ 正确位置 -
<title>...</title> <meta charset="UTF-8">❌ 失效 -
<!-- 注释 --><meta charset="UTF-8">❌ 注释占字节数，可能超 1024 范围 - BOM（
EF BB BF）开头会挤占有效扫描空间，VS Code 保存时务必选UTF-8，**不要选UTF-8 with BOM**
文件实际编码和 meta 声明必须一致
写了 <meta charset="UTF-8">，但文件实际是 GBK 编码保存的，浏览器会用 UTF-8 解码 GBK 字节，每个中文变成两三个乱码字符（如 04）。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- VS Code：右下角看到
GBK，点它 →Reopen with Encoding→ 选GBK看是否恢复中文；确认后 →Save with Encoding→ 选UTF-8 - Linux/macOS 终端验证：
file -i your.html输出应含charset=utf-8 - Notepad++：编码 → 转为 UTF-8 编码（无 BOM）
HTTP 响应头 Content-Type 优先级高于 meta
本地双击打开（file:// 协议）只认 meta；但通过服务器访问时，响应头里的 Content-Type: text/html; charset=GBK 会直接覆盖 meta，哪怕你写了 UTF-8 也白搭。
- Chrome DevTools → Network → 刷新 → 点 HTML 请求 → Headers → Response Headers → 查
Content-Type - Nginx 配置加：
charset utf-8;（在http、server或location块内） - Apache
.htaccess加：AddDefaultCharset UTF-8 - Express.js：
res.setHeader('Content-Type', 'text/html; charset=UTF-8')
真正容易被忽略的是三者必须同时对齐：文件实际编码 = meta charset 值 = HTTP 响应头 charset。少一个，中文就可能断在某个环节。表格只是内容容器，别在 <table> 上浪费调试时间。</table>
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
