html中防止特殊字符冲突的核心是声明utf-8编码防乱码、对动态内容做html实体转义防解析错误和xss；meta charset仅控制字节解码，不干预、&等字符的语法解析，故无法阻止xss或标签误解析。
HTML 中防止特殊字符冲突，核心不是“设置编码”，而是做两件事：一是声明文档字符集（避免乱码），二是对动态插入的内容做 HTML 实体转义（避免解析错误和 XSS）。这两者常被混为一谈，但作用完全不同。
为什么 meta charset="UTF-8" 不能防 和 <code>& 解析错误
很多人以为只要写了 <meta charset="UTF-8">，HTML 就“安全”了——其实它只管字节怎么解码成字符，不管 是不是被当成标签开头。浏览器拿到 UTF-8 字节流后，照样会按 HTML 规范解析语法：<code> 启动标签，<code>& 启动实体引用。如果用户输入了 <script></script> 并直接塞进 innerHTML，meta charset 完全不拦它。
-
meta charset的唯一职责是告诉浏览器：“这堆二进制数据请用 UTF-8 解码” - 它对
、<code>>、&、"、'等字符是否被解析为 HTML 语法，毫无影响 - 没设
meta charset可能导致中文变；设了但没转义用户内容，照样执行 XSS
用户输入进 DOM 前必须 HTML 转义，别依赖 textContent 自动处理
想把一段原始字符串（比如评论、标题）安全地显示在页面上，不能直接 el.innerHTML = userInput。正确做法是先转义再插入：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 用临时元素法：创建
div，赋值temp.textContent = userInput，取temp.innerHTML得到转义后字符串 - 不要反着来：
temp.innerHTML = userInput; temp.textContent会执行脚本，XSS 风险拉满 - 别用
innerText替代textContent：它受 CSSdisplay: none影响，还压缩空白和换行，不可靠 - 服务端同理：PHP 用
htmlspecialchars($s, ENT_QUOTES, 'UTF-8')，Node.js 用he.escape(s)，参数漏掉UTF-8可能导致中文被截断
HTTP 响应头 Content-Type 和 meta charset 冲突时以谁为准
当 HTTP 响应头里有 Content-Type: text/html; charset=GBK，而 HTML 里又写了 <meta charset="UTF-8">，浏览器会优先信任响应头。结果就是：你存的是 UTF-8 文件，服务器却用 GBK 解，中文全变乱码。
- 检查方式：浏览器 DevTools → Network → 选 HTML 请求 → Headers → Response Headers → 查看
Content-Type - Nginx 默认不发 charset，Apache 有时带
ISO-8859-1，静态托管（如 GitHub Pages）通常默认 UTF-8 - PHP 输出前加
header('Content-Type: text/html; charset=UTF-8');；Express 用res.set('Content-Type', 'text/html; charset=utf-8')（注意小写utf-8） -
meta charset必须放在最前面（最好第一行），否则前 1024 字节已按错误编码解析，补救无效
最容易被忽略的点是：前后端协作时，同一段 HTML 字符串在 API 响应里已被服务端转义过一次，前端又调一次 he.escape()，结果变成双重转义——< 显示为字面量 <。约定“传输层不转义，展示层按需转义”比任何库配置都管用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
