htmlspecialchars 应在最终输出到 HTML 页面时调用（如 echo、print），而非存库前；否则会导致搜索失败、JSON 乱码、富文本损坏。
htmlspecialchars 该在哪儿调用才真正起作用
它只对输出到 HTML 的字符串做转义，不是万能过滤器，也不是存数据库前该用的函数。很多人把它当成“防 XSS 全家桶”，结果在入库时就 htmlspecialchars，导致搜索失败、JSON 输出乱码、富文本被破坏。
- 必须在 最终输出到 HTML 页面（比如
echo、=）前调用，且仅针对要当 HTML 内容渲染的变量 - 用户提交的
$_POST['content']如果后续要存进数据库、写入日志、生成 JSON API 响应，此时不能提前htmlspecialchars - 模板里每个动态插入 HTML 的位置，都要单独处理：
<div><?= htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8') ?></div>
ENT_QUOTES 和 UTF-8 编码缺一不可
漏掉这两个参数，等于没防——特别是中文站点，不指定 UTF-8 会导致双字节字符截断，可能绕过转义；不用 ENT_QUOTES 则单引号不会被转义，在属性值中极易触发 XSS。
- 推荐固定写法：
htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, 'UTF-8') -
ENT_HTML5比默认的ENT_COMPAT更严格，兼容现代浏览器解析规则 - 如果 PHP 版本低于 5.4，
htmlspecialchars默认编码是ISO-8859-1，不显式传'UTF-8'就会出问题
为什么 htmlspecialchars 不能替代输入验证和 CSP
它只解决“HTML 上下文中的数据输出”这一种场景。表单提交含 JS 代码、URL 参数里塞 javascript:、CSS 属性里插表达式、甚至 `
- URL 输出要用
urlencode或filter_var($url, FILTER_SANITIZE_URL) - JS 字符串内嵌变量，必须用
json_encode($str, JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS) - HTML 属性值（如
id="<?=$id?>"）仍需htmlspecialchars，但前提是整个属性值是纯文本，不能是拼接出来的 JS 行为 - 真正的兜底是 HTTP 头加
Content-Security-Policy: default-src 'self'
常见错误：自动全局转义或中间件里一刀切
有些老项目在 input_filter 或框架中间件里对所有 $_GET/$_POST 做 htmlspecialchars，结果导致：搜索关键词带引号搜不到、API 返回的 JSON 字段多出一堆 "、富文本编辑器保存的内容被二次转义成 。
立即学习“PHP免费学习笔记（深入）”；
- 永远不要修改原始输入数据的语义——
$_POST应该保持“用户原意”，转义是视图层责任 - 如果真要统一处理，用 Twig/Blade 这类模板引擎的自动转义（它们默认开启），而不是在入口处污染原始数据
- 调试时发现页面显示
<script></script>，八成是重复转义了，检查有没有在入库前、模板里、响应前各转一次
htmlspecialchars 当成 HTML 输出的守门员，别让它去干保安、保洁和程序员的活。 
