thinkphp validate默认不校验参数类型，字符串数字如"123"通过number规则；tp6需用integer规则配合strict或显式转换校验，tp5.1升级后number规则更严格，空格、符号等导致验证失败。
ThinkPHP 的 validate 方法默认不校验参数类型
很多人以为只要写了 ['id', 'number', '必须为数字']，传字符串 "123" 就会失败——其实不会。validate 默认只做“存在性 + 规则匹配”，底层用的是 filter_var 或正则，对字符串数字、浮点字符串都放行。真要强转后比对类型（比如要求 int 而非“能转成 int 的字符串”），得手动干预。
实操建议：
- 在验证规则里加
'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 这类规则不关心类型。
实操建议：
- 不要依赖
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') 是整数，可能只是巧合。
实操建议：
- 一律用
$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，其实是规则更准了。
实操建议：
- 升级后务必检查所有
number/integer/float规则字段的测试用例，特别是含符号、空格、科学计数法的输入 - 需要兼容旧行为？自定义验证规则，例如：
['price', 'callback:checkFloat', '价格格式错误']，函数里用floatval(trim($value))再判断是否非零 - 别在验证规则里写
'float'期望它接受"1.50"——它只认标准浮点字面量，"1.5000"可以，"1.50e0"不一定
最麻烦的不是规则写不对，而是你以为框架替你做了类型归一，其实它只在你明确说“我要整数”且输入恰好是整数时才拦住你。其他时候，它默默把字符串当数字用，直到数据库报错或运算出错才暴露问题。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
