如何实现ThinkPHP请求参数严格类型校验？

本文共计1060个文字，预计阅读时间需要5分钟。

很多人以为只要写了以下内容：

实操建议：

立即学习“PHP免费学习笔记（深入）”；

• 在验证规则里加 'type' => 'integer'（仅 TP6.1+ 支持），但注意它只校验 PHP 类型，不处理自动转换
• 更可靠的做法：先用 input() 拿原始值，再用 intval() / floatval() / (int) 显式转换，然后和原始字符串比对是否“无损”
• 例如判断是否纯整数：$raw = $this->request->param('id'); $num = (int)$raw; if ((string)$num !== $raw) { // 类型不一致 }

TP6 中 Validate 类的 rule 与 scene 对类型校验的影响

场景不同，校验时机和参数来源不同，直接影响类型判断结果。比如 scene('edit') 可能跳过某些字段，而 scene('create') 强制要求 status 是 integer，但如果你传了 "0"，验证仍通过——因为 in:0,1,2 这类规则不关心类型。

实操建议：

立即学习“PHP免费学习笔记（深入）”；

• 不要依赖 in、between 等范围类规则做类型兜底；它们对字符串输入照常匹配
• 需要强类型时，组合使用：['status', 'integer', '状态必须为整数'] + ['status', 'in:0,1,2', '状态值不合法']
• 注意 integer 规则在 TP6.0 中实际调用的是 is_int()，而 input('status') 返回的永远是字符串，所以必须配合 strict => true 或提前转换

用 Request::param() 和 Request::only() 时的隐式类型丢失

Request::param() 默认会对 GET/POST 数据做一次 htmlspecialchars 和基础类型弱转换（如 "1" → 1），但这个行为不可控、不透明，且在不同 PHP 版本或 SAPI 下表现不一致。你看到的 param('id') 是整数，可能只是巧合。

实操建议：

立即学习“PHP免费学习笔记（深入）”；

• 一律用 $this->request->get('id', null, null) 或 post('id') 明确指定来源，避免 param 的混合解析逻辑
• 需要原始未处理值？用 $this->request->get() 全量取，再自己挑字段，别依赖 only(['id', 'name']) ——它内部仍走 param() 链路
• 调试时直接 dump $_GET / $_POST，确认原始数据形态，再决定校验策略

TP5.1 升级到 TP6 后类型校验变松的典型坑

TP5.1 的 validate 在遇到 number 规则时，会尝试用 is_numeric() + 强制转换做兜底；TP6 改为更严格的 filter_var($value, FILTER_VALIDATE_INT)，但默认不开启 flags，导致 "123 "（带空格）或 "+123" 直接失败。你以为是 bug，其实是规则更准了。

实操建议：

立即学习“PHP免费学习笔记（深入）”；

• 升级后务必检查所有 number / integer / float 规则字段的测试用例，特别是含符号、空格、科学计数法的输入
• 需要兼容旧行为？自定义验证规则，例如：['price', 'callback:checkFloat', '价格格式错误']，函数里用 floatval(trim($value)) 再判断是否非零
• 别在验证规则里写 'float' 期望它接受 "1.50"——它只认标准浮点字面量，"1.5000" 可以，"1.50e0" 不一定

最麻烦的不是规则写不对，而是你以为框架替你做了类型归一，其实它只在你明确说“我要整数”且输入恰好是整数时才拦住你。其他时候，它默默把字符串当数字用，直到数据库报错或运算出错才暴露问题。