接口参数校验不通过的主因是数据未抵达校验环节、格式错误或逻辑覆盖不全；需先确认参数是否真实传入（如JSON需用php://input解析）、Content-Type是否匹配、字段名大小写是否一致，再检查校验是否前置执行、是否覆盖空格/null字符串/科学计数法等边缘场景，并统一用$errors数组收集错误、结构化返回。
接口参数校验总不通过，多数不是规则写错了，而是请求数据没到校验环节、格式不对、或校验逻辑没覆盖真实场景。重点先确认“数据是否真的传进来了”，再看“校验是不是在正确位置执行”。
检查请求数据是否被正确接收
很多校验失败其实是前端根本没传值，或后端没拿到——尤其 JSON 请求体、文件上传、大小写字段名不一致时极易出错。
- 在入口处加
var_dump($_REQUEST); exit;，看有没有目标参数；如果是application/json，必须用file_get_contents('php://input')解析，$_POST为空是正常的 - 检查 Content-Type：前端发 JSON 却没设
Content-Type: application/json，PHP 就不会自动解析；反之，表单提交却设成 JSON，也会导致数据丢失 - 留意字段名大小写和下划线：前端传
user_name，后端取username，或传email但代码里写成mail，都会导致isset()返回 false
确认校验逻辑是否覆盖真实输入类型
常见陷阱是只测了理想数据，忽略了空格、字符串数字、null 字符串、科学计数法等边缘情况。
-
empty('0')返回 true，empty(' ')也返回 true，但它们不是真正“空”——校验手机号或ID时要改用trim($val) === '' -
is_numeric('1e5')返回 true，但数据库可能不支持；is_int($_POST['id'])永远为 false，因为表单值全是字符串 - 邮箱、手机号等格式校验，别只依赖正则，优先用
filter_var($email, FILTER_VALIDATE_EMAIL)，它更符合 RFC 标准
验证校验是否在业务逻辑前执行
最隐蔽的问题：校验代码写了，但放在了插入数据库、调用第三方服务之后——失败了也已执行副作用，还掩盖了真实错误。
立即学习“PHP免费学习笔记（深入）”；
- 把所有校验统一放到接口最开头，用数组收集错误：
$errors = [];，每项校验失败就$errors[] = ['field'=>'email', 'msg'=>'邮箱格式错误']; - 校验结束后先判断
if (!empty($errors)) { echo json_encode(['code'=>42200, 'message'=>'参数错误', 'errors'=>$errors]); exit; } - 避免用多个
if (...) { die(...) }，容易漏掉后续字段，也难统一返回结构
用日志+工具还原真实请求链路
光看代码容易误判，必须拿到真实请求数据和执行路径。
- 在关键节点加
error_log("【校验】email={$email}, filter_result=".var_export(filter_var($email, FILTER_VALIDATE_EMAIL), true), 3, '/tmp/api.log'); - 用 Postman 发送原始 JSON（不要用表单模式），手动设置 Headers，并开启「Preserve logs」观察每次请求的完整输入
- 如果用了 Nginx/Apache，检查是否有重写规则截断或修改了请求体（比如
client_max_body_size太小导致大参数被丢弃）
