PHP 接口验参，别把 empty() 当万能判断
接口参数要分清缺失、类型错误、范围不合法。只靠 empty() 挡一层，很容易把合法的 0 当成没传，也容易让脏参数进查询条件。
读取输入 → 判断是否缺失 → 验证类型 → 检查范围 → 再进入业务查询
后台筛选、分页接口、用户资料提交，都离不开验参。很多 php 项目一开始图省事，直接 empty($_get['page'])、empty($_post['email'])，短期看没事，数据一复杂就会出现“0 被吃掉”“字符串进了数字条件”“邮箱格式乱传”这些问题。
场景问答：后台筛选参数该从哪里开始验
拿订单后台筛选页举例：page 要是正整数，email 要像邮箱，status 只能落在允许范围。它们不能共用一套空值判断，因为业务语义完全不同。
• page 缺失时可以给默认值 1。
• email 格式不对时直接提示参数错误。
• status 传了 0 可能是合法状态，不能被 empty() 误杀。
同样是参数，处理策略不该都一样。
我更建议先列字段规则，再写代码。否则后面会变成一堆零散的 if，很快没人敢改。
规则对比：filter_input() 和 filter_var() 怎么选
filter_input() 适合直接从输入来源读取并过滤，比如 INPUT_GET、INPUT_POST。如果参数已经被你放进变量，或者数据来自 JSON、数据库、数组，那就用 filter_var()。
$page = filter_input(INPUT_GET, 'page', FILTER_VALIDATE_INT); $email = filter_var($email, FILTER_VALIDATE_EMAIL);
• FILTER_VALIDATE_INT 是验证，不通过会返回失败值。
• FILTER_VALIDATE_EMAIL 只判断格式，不代表邮箱真实存在。
• FILTER_DEFAULT 等同于 FILTER_UNSAFE_RAW，默认并不安全。
验证是决定能不能用，清洗只是整理输入形态。
很多坑来自把清洗当验证。比如把标签去掉，并不代表这个字符串就能当业务字段直接入库。
错误复盘：empty() 为什么会误伤 0
empty() 会把 0、'0'、空字符串、空数组等都当成空。对分页参数也许还能接受，对状态字段就很危险。订单状态 0 如果表示“未处理”，被当成没传，查询结果就变了。
if ($status === null) {
// 缺失
}
if (!in_array($status, [0, 1, 2], true)) {
// 越界
}
• 缺失判断用是否存在或是否为 null。
• 类型判断和范围判断分开写。
• 状态值用严格比较，避免字符串数字混进来。
0 是业务值，不一定是空。
这种问题不容易报错，只会让结果集变得奇怪。线上排查时，最好把原始参数和规范化后的参数都打进调试日志。
上线检查表：参数进 SQL 前要过这几关
验参不是为了写得好看，是为了让业务层拿到可信数据。尤其是查询接口，参数一旦直接进 SQL 条件，轻则结果不准，重则留下安全风险。
• 缺失参数：给默认值，或返回明确错误。
• 类型校验：整数、邮箱、URL、布尔值各走各的规则。
• 范围校验：page、limit、status 都要有边界。
• 错误返回：给调用方能理解的信息，别把内部细节抛出去。
参数越早收干净，后面的代码越少猜。
如果项目里接口越来越多，可以封装一层小的参数规则表。别追求复杂框架，先把每个字段的类型、默认值和范围说清楚，就已经能挡掉不少线上问题。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
