php filter扩展需手动调用函数，filter_sanitize_string已废弃，应优先用filter_sanitize_full_special_chars（php 8.1+），整数/浮点过滤须显式加标志，filter_input()返回false表示验证失败、空字符串表示输入为空，必须严格区分；数据库写入应使用pdo参数绑定，html输出前用htmlspecialchars而非filter_var替代，多字节编码下须先转utf-8再过滤。
PHP 的 filter 扩展不是靠“开启扩展”就能自动过滤数据的，它本身不拦截或修改输入，只提供一组函数供你主动调用——没手动用 filter_var() 或 filter_input()，就等于没用。
filter_var() 怎么选 filter_id 才不放行恶意数据
很多人用 FILTER_SANITIZE_STRING（已废弃）或模糊匹配 FILTER_SANITIZE_SPECIAL_CHARS，结果 HTML 标签、JS 事件、data: URL 仍能穿透。关键不是“有没有过滤”，而是“过滤后是否还能被解释执行”。
-
FILTER_VALIDATE_EMAIL只校验格式，不清理内容；若后续拼进 mail() 或 SQL，仍需额外转义 - 处理用户昵称/标题等自由文本，优先用
FILTER_SANITIZE_FULL_SPECIAL_CHARS（PHP 8.1+），它等价于htmlspecialchars($str, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8') - 处理整数或浮点数，必须搭配
FILTER_FLAG_ALLOW_THOUSAND等显式标志，否则"1,234"会被判无效——但注意：带逗号的数字不该直接进数据库，应先标准化 - 自定义规则？别硬套
FILTER_CALLBACK包一层 trim() 就完事，回调函数里仍要防 null byte、BOM、零宽空格等边缘字符
filter_input() 读 POST 数据时为什么有时返回 false 而不是空字符串
因为 filter_input() 默认行为是：验证失败 → 返回 false；过滤后为空 → 返回空字符串。混淆这两者会导致逻辑漏洞，比如把 false 当成“用户没填”，实际可能是输入了 "<script>"</script> 被 FILTER_VALIDATE_URL 拒绝了。
- 始终用严格比较：
if ($val === false)判断验证失败，if ($val === '')判断为空 - 不要依赖默认
FILTER_DEFAULT（等价于无过滤），必须显式传入FILTER_SANITIZE_*或FILTER_VALIDATE_* - 从
INPUT_SERVER读HTTP_USER_AGENT时，别用FILTER_SANITIZE_ENCODED—— 它会把空格变 +，破坏 UA 结构
和 htmlspecialchars()、preg_replace() 混用时的典型冲突场景
常见错误是“先 filter_var(..., FILTER_SANITIZE_SPECIAL_CHARS)，再 htmlspecialchars()”，结果引号被双重编码成 "，前端显示异常。安全处理必须分层明确：哪里做验证、哪里做输出编码、哪里做上下文转义。
- 数据库写入前：用
filter_var($str, FILTER_SANITIZE_STRING)已不够，应改用 PDO 参数绑定，或至少用mysqli_real_escape_string()（仅限旧项目） - HTML 输出前：直接
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')，别依赖filter_var($str, FILTER_SANITIZE_SPECIAL_CHARS)替代——后者不处理<style></style>内的 JS - JS 字符串内插值：
filter_var()完全无效，必须用json_encode($str, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG)
真正容易被忽略的是：filter 扩展对多字节编码（如 GBK）的边界处理不一致，FILTER_VALIDATE_INT 在非 UTF-8 编码下可能截断或误判。如果项目还混用 mb_internal_encoding('GBK')，请先统一转 UTF-8 再过滤——否则任何 filter 都可能失效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
