XSS防护核心是按上下文做输出编码，而非输入过滤或删标签；响应式HTML不改变此逻辑，关键在用户输入如何进入DOM及落在哪个上下文，如innerHTML赋值前必须转义，否则等于开后门。
响应式 HTML 本身不改变 XSS 防护逻辑——安全关键点不在“是否响应式”，而在“用户输入如何进入 DOM”以及“输出时落在哪个上下文”。所有响应式页面只要渲染用户数据，就必须按上下文做对应防护，否则 viewport 缩放再完美也挡不住 onclick 执行。
htmlspecialchars() 用错上下文等于没防
很多人把 htmlspecialchars() 当成万能盾牌，但它的作用域非常窄：只适用于纯文本插入（如 <p>内容</p>、title 属性、<textarea> 的 value）。一旦用户输入要进 href、onclick 或 style，它就完全失效。
- 错误示例：
echo '<a href="' . htmlspecialchars($url) . '">链接</a>'——javascript:alert(1)经htmlspecialchars()后仍是合法 JS URL - 正确做法：对 URL 先用
filter_var($url, FILTER_VALIDATE_URL)，再白名单校验协议（只允许http://、https://、/） - 对内联 JS 上下文（如
onclick），根本不能拼字符串，应改用事件绑定 +textContent或框架的表达式绑定
strip_tags() 保留标签 ≠ 安全
strip_tags($input, '<p><strong>')</strong></p> 看似可控，实则危险。它不解析 HTML 结构，只删掉 和 <code>> 符号之间的内容，onclick、onerror、javascript: 这类属性会被原样留下。
- 输入：
<p onclick="alert(1)">点我</p>→ 输出：<p onclick="alert(1)">点我</p>（onclick毫发无损） - 它适合的场景极有限：后台导出日志为纯文本、邮件摘要生成、临时清洗旧数据
- 绝不能用于前端直出、评论区、富文本编辑器输出前的“简易过滤”
富文本必须用 HTMLPurifier，且必须显式配白名单
任何基于 preg_replace 或 str_replace 的自研“HTML 过滤器”，面对 <!--<script>-->、<div style="x:expression(alert())"> 都会崩溃。浏览器的 HTML 解析规则远超正则能力。
立即学习“前端免费学习笔记（深入）”；
- 安装后必须配置
HTML.Allowed，例如'a[href|title],strong,em,p,br,ul,ol,li'；默认配置几乎禁全部，不设就等于没开 - 禁用
HTMLPurifier_Config::createDefault()的宽松模式，否则可能放行危险属性 - 性能开销大，不适合每请求处理多段文本；建议只在入库前或模板渲染前做一次
- 别在存储时净化一遍、输出时又净化一遍——重复处理会把
©变成©，显示异常
前端插入必须避开 innerHTML
响应式页面常动态更新 DOM，但直接写 element.innerHTML = userInput 是高危操作，无论是否加了媒体查询或 flex 布局。
- 安全替代：用
element.textContent = userInput（纯文本）或element.append(document.createTextNode(userInput)) - 若真需插入 HTML（如 CMS 富文本），必须先经服务端净化（如 HTMLPurifier），前端再用
DOMPurify.sanitize()二次校验 - 现代框架（React/Vue）自动转义
{userInput}，但遇到v-html或dangerouslySetInnerHTML时，必须确保传入的是已净化内容
最易被忽略的一点：响应式设计常伴随 AJAX 加载、动态 tab 切换、懒加载模块——这些场景下，开发者容易忘记对新插入的用户数据做上下文适配的输出编码，以为“页面整体是响应式的，所以安全也继承了”。其实每次 DOM 插入都是独立的安全边界，该转义还得转义，该校验还得校验。
