phpenv 中 filter 扩展无需手动开启，因其自 php 5.2.0 起即为内核组件，非独立模块，故无 filter.so 或 extension=filter.ini；验证需三步：检查函数存在、列出过滤器、实测 filter_var() 返回值。
phpEnv 下无需手动开启 filter 扩展——它从 PHP 5.2.0 起就是内置核心组件，只要 phpEnv 使用的是 PHP 5.2+（所有现代版本都满足），filter 就已就绪，直接调用 filter_var() 等函数即可生效。
为什么在 phpEnv 中找不到 filter.so 或 extension=filter.ini？
因为 filter 不是独立扩展模块，而是 PHP 内核的一部分。你在 phpinfo() 页面里搜 “filter” 能看到完整支持列表，但不会出现 “Loaded Modules” 里的 .so 行；php -m | grep filter 也查不到——这不是缺失，是设计如此。试图在 php.ini 里加 extension=filter 反而会报错 “unable to load dynamic library”。
验证 filter 是否真正可用的三步检查法
- 运行
php -r "var_dump(function_exists('filter_var'));"，输出bool(true)即确认函数存在 - 执行
php -r "print_r(filter_list());"，应返回包含FILTER_VALIDATE_EMAIL、FILTER_SANITIZE_FULL_SPECIAL_CHARS等数十个常量的数组 - 手写测试代码：
var_dump(filter_var("123", FILTER_VALIDATE_INT));，正确返回int(123)而非false或警告
FILTER_SANITIZE_STRING 已废弃，PHP 8.1+ 必须换用替代方案
如果你在旧项目里看到 FILTER_SANITIZE_STRING，它早在 PHP 8.1 中被彻底移除。现在对应场景要拆解处理：
- HTML 输出前防 XSS：改用
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')，别用任何 sanitize 过滤器替代 - 通用字符串清理（去空格/非法字节）：用
FILTER_SANITIZE_FULL_SPECIAL_CHARS（PHP 8.1+ 新增）或FILTER_SANITIZE_SPECIAL_CHARS（兼容旧版，但不处理 Unicode 边界） - 数据库写入：严禁依赖 filter 扩展做“安全化”，必须走
PDO::prepare()+ 参数绑定，filter_var()只能用于格式校验 - 多字节字符串（如中文）：先用
mb_convert_encoding($input, 'UTF-8', 'auto')统一编码，再过滤，否则FILTER_SANITIZE_EMAIL等可能误删有效字符
最容易被忽略的一点：filter 函数返回值类型不统一——FILTER_VALIDATE_* 成功时返回原值（可能是 int/string），失败时返回 false；而 FILTER_SANITIZE_* 永远返回 string，哪怕输入是 null 或数字。用 === 严格比较时，这点会直接导致逻辑翻车。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
