必须转义的字符只有五个：&、<、>、"、'；漏转会导致HTML解析错误、XSS漏洞或页面结构崩溃，其中&最危险，未转义会引发连锁实体解析错误。
哪些字符必须用&<>"'转义
只这五个：&、、"、'。漏掉任意一个，HTML解析就会出问题——不是标签错位，就是内容截断，甚至触发XSS。
常见错误现象：Unclosed entity报错、©显示成方块、<p>5 </p>被切开成<p>5 </p>和10两段、用户输入的<script></script>真的执行了。
&最危险：不先转成&，后面紧跟着的lt;会被当成，但<code>©里&没转，整个实体就失效。
立即学习“前端免费学习笔记（深入）”；
和<code>>在纯文本中不转，浏览器会尝试匹配闭合标签，比如5 可能被解析成<code><code>5+10-
"在title="他说 "Hello""里必须写成title="他说 "Hello""，否则引号提前闭合 -
'在单引号属性值中用'更稳；IE8及更早版本不支持'
中文书名号《》该用UTF-8直输还是实体
优先直输《三体》，但前提是文件存为UTF-8无BOM、且<meta charset="UTF-8">已声明。否则《会变问号或方框。
实体编码仅作兜底：左书名号、右书名号。别用«/»（那是西文角括号‹›，不是中文书名号）。
注意：是十进制，十六进制写法‘虽合法，但部分XML解析器或旧RSS工具不认，生产环境慎用。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- VS Code/Sublime Text保存时选“UTF-8 without BOM”
- 检查HTTP响应头是否含
Content-Type: text/html; charset=UTF-8 - 如果后端模板（如Jinja、Django）自动转义，再手动加
会导致双重编码，显示为字面量
innerHTML里插入带符号的字符串怎么不崩
往element.innerHTML写任何内容前，必须确保它已是安全的HTML字符串——要么由你完全控制，要么已做过转义。不能把用户输入原样拼进去。
错误做法：el.innerHTML = "价格：" + price + "元，库存：" + stock + " ——<code>一出现，DOM结构就乱。
正确做法分两种场景：
- 只想显示纯文本：用
textContent，天然免疫解析风险，el.textContent = "库存：" + stock + " 会原样显示 - 必须保留HTML结构：先转义再拼接，顺序固定：
.replace(/&/g, '&') → .replace(/, '<') → .replace(/>/g, '>') → .replace(/"/g, '"') → .replace(/'/g, ''') - 框架中：React默认走
textContent语义，dangerouslySetInnerHTML才是唯一需警惕的出口；Vue同理，v-html传入前确认没被额外转义
为什么写了©还是显示方块
大概率不是实体写错了，而是编码声明或上下文错位。关键检查点有三个：
第一，<meta charset="UTF-8">是否在最开头？位置靠后或缺失，浏览器可能按ISO-8859-1解析。
第二，服务器返回的HTTP头Content-Type是否明确指定charset=UTF-8？光有meta标签不够，两者必须一致。
第三，文件本身是否真为UTF-8无BOM？用file -i filename.html或编辑器编码检测功能验证。Windows记事本另存为UTF-8时默认带BOM，会导致某些解析器失败。
容易被忽略的是：实体必须以;结尾。©无效，©才正确；©也不行——&必须第一个转义，否则浏览器以为这是个新实体起点。
