php 8.5.7 并不存在——截至2026年7月，官方最新稳定版是php 8.3.12，所谓“8.5.7”属虚构版本，所有基于该编号的功能、安全机制或配置均无事实依据，审计时须溯源确认是否为误标、私有分支或混淆版本。
PHP 8.5.7 并不存在——官方最新稳定版是 PHP 8.3.12（截至 2026 年 7 月），所谓“8.5.7”属虚构版本，所有基于该编号的过滤器行为、函数新增或安全机制均无事实依据。审计时若发现项目文档或配置中写有 PHP_VERSION == '8.5.7' 或依赖其特性，应立即定位来源：是内部私有分支、误标镜像标签，还是混淆了其他语言/框架的版本号。
filter_var 系列函数在真实 PHP 版本中的行为边界
当前主流 LTS 版本（如 8.3.x）中，filter_var 是输入校验唯一推荐入口，但它不等于“过滤器”，更不是 XSS 防护工具：
-
FILTER_SANITIZE_SPECIAL_CHARS和已废弃的FILTER_SANITIZE_STRING不同：前者等价于htmlspecialchars($input, ENT_COMPAT, 'UTF-8')，仅用于输出前转义，**不能存库** -
FILTER_SANITIZE_FULL_SPECIAL_CHARS（PHP 8.1+ 引入）才是输入阶段可用的轻量清理，会移除 null 字节、修复非法 UTF-8，并转义&<code>>"—— 但它不处理'，也不防javascript:协议注入 - 对邮箱、URL、整数等类型验证，必须搭配
FILTER_VALIDATE_*，且返回false时需显式判断，不能直接用结果参与逻辑 -
filter_input()的FILTER_UNSAFE_RAW模式默认开启，意味着不加 flag 就等于裸奔；很多旧代码漏写 flag，导致看似“过滤”实则无效
别把 htmlspecialchars 当输入过滤器用
常见审计红线：在接收请求后第一行就调用 htmlspecialchars($_POST['content']) 再入库。这会导致三重问题：
- 数据库里存的是
<script></script>这类实体，后续 API 返回、导出 Excel、发邮件时全部显示为源码，而非渲染效果 - 搜索失效：用户搜 “
