直接向table或textarea写入未转义的用户输入会引发XSS漏洞；安全做法是用textContent或value属性，危险做法是拼接innerHTML或使用document.write；表格内容需按HTML/属性上下文分别转义，富文本须白名单过滤标签、属性和协议。
直接往 <table> 或 <code><textarea></textarea> 里塞用户输入，不转义就渲染，等于把 XSS 入口焊死在 DOM 上——哪怕只是显示一条评论或回显表单值，<script></script>、onerror、javascript: 都可能被触发。
textarea 的 value 属性不解析 HTML，但 innerHTML 会
<textarea></textarea> 本身是“纯文本容器”，它的 value 属性写入任意字符串都不会执行脚本；但很多人误用 innerHTML 去填充内容，或者把用户数据拼进模板字符串再赋给 innerHTML，这就立刻翻车。
- 安全写法：
el.value = userInput—— 浏览器原生不做解析，<script></script>就是普通字符 - 危险写法：
el.innerHTML = `<textarea>${userInput}</textarea>`——userInput里带<img onerror="..." alt="HTML表格与文本域防止脚本注入的处理技巧" >就会在插入时触发 - 更隐蔽的坑：
document.write('<textarea>' + userInput + '</textarea>')同样高危，document.write会重解析整个字符串
table 单元格内容必须按上下文转义
表格单元格（<td>、<code><th>）属于 HTML 内容上下文，<code>、<code>>、&、"、' 这五个字符必须转义，否则攻击者输 <img src="x" onerror="alert(1)" alt="HTML表格与文本域防止脚本注入的处理技巧" > 就能弹窗。
- 纯文本展示：优先用
cell.textContent = userInput，零风险 - 需保留简单格式（如换行、
<br>）：先用DOMPurify.sanitize(userInput, { ALLOWED_TAGS: ['br'] })，再赋给cell.innerHTML - 绝对别写：
cell.innerHTML = '<td>' + userInput + '</td>'—— 拼接字符串前没转义，等于邀请 XSS 入室 - 服务端模板中（如 Jinja2）：
{{ user_input }}安全，{{ user_input|safe }}危险，除非你 100% 确认它已过白名单净化
富文本表格内容要过滤属性和协议
如果业务允许用户在表格里贴链接或图片（比如后台 CMS 表格编辑器），光允许可信标签不够，<a href="javascript:..."></a> 或 <img src="data:text/html;base64,..." alt="HTML表格与文本域防止脚本注入的处理技巧" > 仍可执行代码。
立即学习“前端免费学习笔记（深入）”；
- 必须限制 URL 协议：
allowedSchemesByTag: { a: ['http', 'https'], img: ['http', 'https'] } - 禁止事件属性：
ALLOWED_ATTR: ['href', 'src', 'alt', 'title']，砍掉所有onclick、onerror、onload - Node.js 推荐用
sanitize-html，Python 用bleach.clean()，都得显式声明白名单，不能只靠strip_tags()或正则删<script></script> - 特别注意：
<td title="xxx"> 这类属性值属于“属性上下文”，<code>"和'必须单独转义，不能只做 HTML 实体转义最常被忽略的是混合上下文：比如把用户输入先 JSON.stringify() 进 JS 变量，再用该变量拼进
innerHTML。这时候 JS 转义和 HTML 转义必须分层处理，漏一层就破防。
