filter_var()仅做语法校验或字符清洗，不处理业务逻辑、不防XSS、不验证数据真实性；邮箱验证只检格式，数字清洗不等于验证，URL/IP需显式指定flag，特殊字符转义不能替代上下文感知编码。
别指望 filter_var() 一把梭完所有验证和过滤任务——它只做语法校验或字符清洗，不负责业务逻辑、不防XSS、也不保证数据真实存在。
filter_var() 验证邮箱时为什么返回 true 却发不出邮件？
因为 FILTER_VALIDATE_EMAIL 只检查格式是否合法：有没有 @、有没有域名部分、有没有连续点等。它不查 DNS、不连 SMTP、不验证邮箱是否真能收信。
- 空字符串、
"@"、"user@.com"都会返回false - 国际化邮箱（含中文或 emoji）在 PHP 7.2+ 中可能被误判，需先用
idn_to_ascii()转义再传入 - 若要兼顾 IDN，建议组合：
filter_var(idn_to_ascii($email), FILTER_VALIDATE_EMAIL) - 生产环境真正需要“邮箱可用性”时，应走异步验证流程（如发送确认邮件），而非依赖
filter_var()
数字验证为什么不能只用 FILTER_SANITIZE_NUMBER_INT？
清洗不是验证。FILTER_SANITIZE_NUMBER_INT 会把 "123abc456" 变成 "123456"，看似“变干净了”，但原始输入意图已丢失——用户可能本意是提交带单位的字符串，不是整数。
- 正确做法是两步：先清洗，再验证
filter_var(filter_var($input, FILTER_SANITIZE_NUMBER_INT), FILTER_VALIDATE_INT) - 验证浮点数时注意：
FILTER_VALIDATE_FLOAT默认允许科学计数法（如"1e3"），如需禁用，加选项['options' => ['decimal' => '.']] - 负号后带空格（如
"- 123"）会被清洗为"-123"，但验证仍失败——因为清洗不修复语义错误
URL 和 IP 验证最容易踩的 flag 坑
FILTER_VALIDATE_URL 默认只认 http://、https://、ftp://；www.example.com 直接返回 false。IP 验证则默认只走 IPv4 分支，IPv6 必须显式加 FILTER_FLAG_IPV6。
立即学习“PHP免费学习笔记（深入）”；
- 防伪协议绕过：务必搭配
FILTER_FLAG_SCHEME_REQUIRED | FILTER_FLAG_HOST_REQUIRED，否则"javascript:alert()"也能过 - 带端口的 IPv4（如
"192.168.1.1:8080"）不是合法 IP 字符串，FILTER_VALIDATE_IP会失败——端口不属于 IP 范围，应单独提取并验证 - URL 中含中文路径？必须确保传入的是已 URL 编码的字符串，
FILTER_VALIDATE_URL不处理编码逻辑
为什么 FILTER_SANITIZE_SPECIAL_CHARS 不是 XSS 防护方案？
它只转义 &、"、'、、<code>>，而 XSS 可发生在 JavaScript 属性、CSS 表达式、事件处理器、URL 参数甚至 `<script>` 标签内部——这些上下文需要不同编码策略。</script>
- HTML 输出用
htmlspecialchars($str, ENT_QUOTES, 'UTF-8') - JavaScript 字符串内插用
json_encode($str, JSON_UNESCAPED_UNICODE) - URL 参数用
urlencode($str) - 绝对不要用
FILTER_SANITIZE_SPECIAL_CHARS替代上下文感知的输出编码
真正难的不是写对一行 filter_var()，而是分清「这里该验证还是该清洗」「该在哪一层做」「失败后怎么反馈给用户而不泄露系统细节」——这些边界，filter_var() 从不替你判断。
