htmlspecialchars() 是输出用户数据到 HTML 的首选函数，需指定 ENT_QUOTES 和 UTF-8 参数；JS 上下文须先 json_encode() 再 htmlspecialchars()；富文本需用 HTMLPurifier 白名单过滤。
htmlspecialchars() 是最常用也最该优先用的函数
PHP 输出用户数据到 HTML 页面时，htmlspecialchars() 是第一道也是最关键的防线。它把 、<code>>、"、'、& 这五类字符转成 HTML 实体，让浏览器不再当标签或脚本解析。
- 默认只转双引号（
ENT_COMPAT），如果输出在单引号属性里（比如data-id='=$id?>'），得显式加ENT_QUOTES参数 - 不传
UTF-8编码参数，在非 UTF-8 页面里可能截断多字节字符，导致后续内容被“逃逸”出来 - 别用
htmlentities()替代——它会转更多字符，可能破坏用户名里的 emoji 或外文符号，且不解决核心风险
<div class="title"><?php echo htmlspecialchars($user_input, ENT_QUOTES | ENT_HTML5, 'UTF-8'); ?></div>
输出到 JavaScript 或 JSON 里不能只靠 htmlspecialchars()
htmlspecialchars() 对 JS 上下文完全无效。比如把用户输入塞进 var msg = "= $input ?>";，攻击者填入 ";alert(1)// 就直接执行了。
- 必须先用
json_encode()序列化，再用htmlspecialchars()包一层（顺序不能反） -
json_encode()要加JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS，否则仍可能绕过 - 直接拼接 JS 字符串是高危操作，优先改用 data 属性 + 前端 JS 读取，或者走纯 AJAX 接口
<script> const data = <?php echo htmlspecialchars(json_encode($user_data, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS), ENT_QUOTES, 'UTF-8'); ?>; </script>
echo vs. printf 与自动转义模板引擎的陷阱
原生 PHP 中，echo 和 printf() 都不做自动转义，哪怕你写 printf('<span>%s</span>', $user)，照样要自己套 htmlspecialchars()。
- Laravel 的
{{ $var }}、Twig 的{{ var }}默认转义，但{!! $var !!}或{{ var|raw }}会跳过——这些地方最容易漏审 - 自定义函数封装
echo htmlspecialchars(...)很常见，但要注意是否覆盖了所有编码场景（比如 XML 输出要用htmlspecialchars($s, ENT_XML1)） - 框架里有时
$request->input()看似“干净”，其实只是没过滤，不是已转义
特殊场景：富文本和允许部分 HTML 的例外处理
真需要渲染用户提交的富文本（如后台编辑器内容），htmlspecialchars() 就不能用了——它会把所有标签都干掉。
立即学习“PHP免费学习笔记（深入）”；
- 用
HTMLPurifier这类白名单过滤器，而不是正则删<script></script>——正则永远防不住嵌套、注释、大小写混淆等绕过 -
strip_tags()看似简单，但它不校验属性（比如<img src="x" onerror="alert(1)" alt="PHP怎么输出HTML_safe输出避免注入技巧【技巧】" >），也不处理 CSS 表达式，别在生产环境用 - 即便用了净化器，也要限制协议（禁用
javascript:、data:）、禁止内联样式、关闭style标签——这些都在配置里，不是开箱即用
输出 HTML 安全不是选一个函数就完事，而是每处输出都要明确上下文：是 HTML 文本？属性值？JS 字符串？URL？不同位置，逃逸路径完全不同。漏掉任意一种，前面全白做。
