filter_var仅适用于基础格式校验，业务规则需自定义函数实现；应标准化输入、结构化错误返回、分层校验以保障数据质量与可维护性。
PHP中用filter_var做基础格式校验是否够用
不够用。它只覆盖邮箱、URL、IP等通用格式，无法表达“订单金额必须大于0且小于100万”“手机号必须是11位且以13/15/17/18开头”这类业务规则。
实际项目里，filter_var 适合做第一道轻量过滤（比如剔除明显非法的邮箱），但核心业务规则必须自己写逻辑判断。否则上线后会出现“数据入库了，但业务系统读取时报错”的情况。
- 别把
filter_var($val, FILTER_VALIDATE_EMAIL)当成“已通过质检”，它不校验邮箱是否存在、是否被禁用 - 数字类字段慎用
FILTER_VALIDATE_FLOAT，它接受"1e5"这种科学计数法，而财务系统通常要求显式十进制字符串 - 中文姓名、地址等字段，
filter_var完全无能为力，得靠正则或字符集白名单
如何组织业务规则校验逻辑才不容易失控
把每条规则封装成独立函数，函数名直接体现业务含义，比如 is_valid_order_amount()、is_valid_mobile_format()，而不是笼统叫 check_field()。
关键不是“能不能写出来”，而是后续改规则时能否快速定位、不影响其他字段。常见失控点是把所有校验塞进一个大数组配置里，结果加一条新规则要改三处：配置、提示文案、错误码映射。
立即学习“PHP免费学习笔记（深入）”；
- 每个函数只返回
bool，不拼接错误信息——错误文案由上层统一管理，方便多语言和前端展示 - 函数参数固定为
$value和可选的$context（比如当前用户ID、所属门店），避免从全局变量读状态 - 对耗时操作（如查数据库判断是否重复）加明确前缀，例如
is_duplicate_user_phone_in_db()，提醒调用方注意性能
空值、NULL、空字符串、"null"字符串怎么统一处理
这是数据质量检核里最常翻车的地方。PHP里 empty()、is_null()、== ""、=== "" 行为差异极大，而业务规则往往要求“该字段必填”，但上游可能传 null、""、"null"、"undefined" 甚至空白空格。
建议在进入业务规则函数前，先做标准化清洗，再交给校验函数。不要让 is_valid_mobile_format(" ") 返回 true。
- 用
trim($val)去首尾空格，再判断是否为空——否则" 13812345678 "会过不了正则 - 对 JSON 接口传来的
"null"字符串，用json_decode($val, true) === null && $val !== 'null'区分真 null 和字符串 "null" - 数据库字段定义为
NOT NULL DEFAULT ''的，代码里就默认按字符串处理，别假设它一定是string
为什么简单 return false 不足以支撑数据质量报告
生产环境需要知道“哪条记录、哪个字段、违反了哪条规则、原始值是什么”，而不是笼统抛出 ValidationException 就完事。否则运维查问题要翻日志、比对原始报文，效率极低。
推荐返回结构化错误详情，哪怕只是个关联数组。后续导出 CSV 或推送到数据质量平台都靠这个结构。
return [
'field' => 'mobile',
'rule' => 'must_be_11_digits_starting_with_13_15_17_18',
'value' => $input['mobile'],
'reason'=> 'length is 10'
];
复杂点在于：同一字段可能触发多条规则（比如手机号既长度不对，又含字母），这时候要控制校验顺序——先做低成本检查（长度），再做高成本检查（DB去重），避免无效查询。
真正难的不是写校验逻辑，是让规则可追溯、可统计、可下钻到单条数据。这点在初期设计函数接口时就得想清楚。
