php输出用户输入必须用htmlspecialchars()转义，且需指定ent_quotes | ent_html5和utf-8；json输出须用json_encode()；富文本须用htmlpurifier等专用库净化；http头和csp仅为补充，不可替代输出转义。
PHP输出时必须用htmlspecialchars()转义
用户输入的内容只要未经处理就直接进HTML上下文，XSS就几乎必然发生。最常见错误是只对表单提交做“过滤”，却在模板里直接echo $user_input——这等于把攻击载荷原样塞进页面。
正确做法是在**每次输出到HTML内容区域前**调用htmlspecialchars()，且必须指定ENT_QUOTES和UTF-8：
echo htmlspecialchars($user_input, ENT_QUOTES | ENT_HTML5, 'UTF-8');
-
ENT_QUOTES确保单引号也被转义（防止onclick='alert("xss")'绕过） -
ENT_HTML5适配现代HTML解析规则，比默认ENT_COMPAT更安全 - 不传
charset参数在老版本PHP中可能误判编码，导致双字节绕过 - 别用
htmlentities()替代——它会过度编码非ASCII字符，影响中文等正常显示
JSON输出不能靠htmlspecialchars()，得用json_encode()
前后端分离场景下，PHP常通过echo json_encode($data)返回数据。这时候如果把用户输入拼进JSON字符串再手动echo，比如"name": "<?php echo $name; ?>"，htmlspecialchars()完全无效——因为JSON不是HTML。
- 必须用原生
json_encode()，它自动对双引号、反斜杠、控制字符和U+2028/U+2029等JS特殊字符做转义 - 加上
JSON_UNESCAPED_UNICODE保证中文不被编码成\uXXXX - 避免自己拼JSON字符串，哪怕加了
htmlspecialchars()也挡不住"闭合后的JS执行 - 如果要内联到HTML的
<script></script>里，额外用JSON_HEX_TAG防闭合
富文本场景下htmlspecialchars()不够用，得用专用库
用户需要发带链接、加粗的文字？这时禁掉所有HTML标签又太死板，但放行<a></a>、<strong></strong>又容易漏掉onerror、javascript:伪协议等漏洞。
-
strip_tags()不安全——它只删标签，不清理属性里的JS事件或危险协议 - 不要自己写正则过滤HTML，规则复杂度远超预期（比如
<img src="x" onerror="alert(1)">有几十种变体） - 用
HTMLPurifier这类成熟库，配置白名单：允许哪些标签、哪些属性、哪些协议（如只允http://和https://） - 即使用了净化库，输出到HTML前仍要过一遍
htmlspecialchars()——净化后的内容可能含用户可控的属性值，需二次防御
HTTP响应头和CSP能补位，但不能替代输出转义
有人觉得加个X-XSS-Protection: 1; mode=block或Content-Security-Policy: default-src 'self'就能高枕无忧。其实这些只是最后一道防线，对反射型XSS有一定缓解，但对存储型、DOM型基本无效。
-
X-XSS-Protection在Chrome 78+已弃用，Firefox从不支持，别依赖 - CSP的
script-src能拦外链和内联脚本，但无法阻止<img src="x" onerror="...">这种HTML上下文攻击 - CSP需要严格配置，比如漏掉
'unsafe-inline'却忘了移除所有onclick属性，策略就形同虚设 - 真正可靠的只有：输入不做信任、输出必转义、富文本必净化——其他都是锦上添花
最容易被忽略的是模板引擎的“自动转义”开关。Twig默认开启，但Smarty、Blade都可能关着；即使开着，{{ raw_data|raw }}或{!! $data !!}这种显式取消转义的写法，一不小心就绕过了全部防护。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
