PHP 8.3表单验证教程：用户输入数据校验方法

一个核心事实是：PHP 8.3 仍然没有内置一个现成的“表单验证框架”。这意味着，处理用户输入时，filter_var() 和 filter_input() 依然是核心工具，但开发者需要手动组合规则、执行验证与数据清洗。整个过程需要清晰的逻辑，它无法自动绑定表单字段或返回结构化的错误信息。

使用 filter_input() 读取与初步过滤

直接访问 $_POST['email'] 存在风险，因为它未经过任何类型或范围检查，空字符串、空格、超长值或恶意内容都可能被接收。相比之下，filter_input() 的优势在于能一步完成数据读取、类型转换和基础校验。

• 例如，filter_input(INPUT_POST, 'age', FILTER_VALIDATE_INT, ['options' => ['min_range' => 1, 'max_range' => 120]]) 会直接返回整数或 false，而非字符串 "18"。
• 对于邮箱字段，可先用 filter_input(INPUT_POST, 'email', FILTER_SANITIZE_EMAIL) 进行清洗，但需注意：清洗不等于验证。FILTER_SANITIZE_EMAIL 仅会静默删除非法字符，不会报错。因此之后必须用 filter_var($email, FILTER_VALIDATE_EMAIL) 进行二次验证。
• 重要提示：在 PHP 8.3 中，所有 FILTER_SANITIZE_* 系列过滤器已被标记为弃用（其中 FILTER_SANITIZE_STRING 已被彻底移除）。安全的做法是改用 FILTER_SANITIZE_SPECIAL_CHARS，或直接使用 htmlspecialchars() 进行手动转义。

filter_var() 验证需注意语义边界

filter_var() 在验证邮箱、URL、IP 时，其内置标准可能与业务需求存在差距。例如，filter_var('test@localhost', FILTER_VALIDATE_EMAIL) 会返回 true，但多数业务场景不接受本地域名。同样，filter_var('127.0.0.1', FILTER_VALIDATE_IP) 能通过验证，但这可能并非期望的公网 IP 地址。

• 邮箱验证：建议在校验后追加正则表达式，以限制长度和域名格式。例如：preg_match('/^[a-zA-Z0-9._%+-]{1,64}@[a-zA-Z0-9.-]{1,63}\.[a-zA-Z]{2,}$/', $email)。
• URL 验证：使用 FILTER_VALIDATE_URL 会接受如 ja vascript:alert(1) 这样的危险协议。因此，必须额外编写逻辑来拒绝 ja vascript:、data: 等非 HTTP(S) 协议。
• IP 验证：若仅需 IPv4 地址，请显式加上 FILTER_FLAG_IPV4 标志。如需排除私有地址，则需自行实现类似 ip_is_private($ip) 的函数进行检查。

自定义验证逻辑与错误处理

自定义验证必须在数据写入数据库前完成，一个常被忽略的细节是：验证失败时需要保留用户的原始输入。

例如，用户输入了手机号 138****1234（含星号）。验证逻辑可能仅用正则检查格式，但若存库前未清理星号，脏数据便会被写入。另一个常见错误是使用 trim() 后，忘记将结果重新赋值给变量。

• 正确流程是：先统一处理，$input = filter_input(INPUT_POST, 'phone', FILTER_SANITIZE_FULL_SPECIAL_CHARS)，然后再进行清洗，例如 $clean = preg_replace('/[^0-9+]/', '', $input)。
• 当校验失败时，应将原始的 $input 传回前端模板，而非清洗后的 $clean。否则用户将看到被清空的输入框，体验不佳。
• 此外，不建议在验证函数内部直接使用 die() 或进行重定向。PHP 8.3 的错误处理更倾向于抛出 ValueError 等异常，便于在上层统一捕获和处理。

归根结底，真正的挑战往往不在于语法本身，而在于那些模糊的边界。例如，用户名允许 Unicode 字符但禁止 emoji，密码要求包含大小写字母和数字但不能有连续重复字符——这些复杂规则，filter_var() 无法处理，都需要开发者手动实现逻辑。