ThinkPHP参数格式自动修正方法

ThinkPHP 的 input() 默认不自动修正参数格式，仅原样返回 filter_input() 或 $_GET/$_POST 解析后的值；类型转换需依赖修饰符（如 /d、/s）或手动处理，关键字段必须显式校验。

ThinkPHP 的 input() 默认不自动修正参数格式

它只是原样返回经过 PHP filter_input() 或 $_GET/$_POST 解析后的值，不会帮你把字符串 "1" 转成整数 1，也不会把空数组 [] 当作缺失字段忽略。所谓“智能修复”，其实是靠开发者在接收时主动干预。

常见错误现象：input('id') 返回字符串 "123"，但后续直接用于数据库查询或类型强校验时出错；input('tags') 是空字符串 "" 而不是 null 或空数组，导致 in_array() 判断失效。

• 使用场景：API 接口接收前端传参（尤其来自表单、axios、小程序），字段类型混杂
• 参数差异：input('id/d') 中的 d 表示强制转为整型，s 强制字符串，a 强制数组，b 强制布尔 —— 这些过滤修饰符才是“修正”的实际入口
• 性能影响极小，底层调用的是 PHP 内置类型转换，无额外循环或正则

用 input() 修饰符做基础类型归一化

ThinkPHP 的 input() 支持在键名后加斜杠 + 类型标识符，这是最轻量、最常用的“修正”方式，比手动 (int) 或 intval() 更安全（会处理空值、非数字字符串等边界）。

示例：input('page/d', 1) —— 如果请求没传 page 或传了 page=abc，都会回退到默认值 1；若传了 page=2.7，则截断为 2。

• /d：转整型（含 0、负数），非法值 → 默认值
• /s：转字符串，自动去除首尾空白（trim()），空值 → 空字符串
• /a：确保是数组，字符串如 "a,b,c" 不会自动拆，需配合 explode() 手动处理
• /b：转布尔，"1"、"on"、"true"（不区分大小写）→ true；其余（含 "0"、""）→ false

复杂结构（如嵌套数组、JSON 字段）不能只靠 input() 修饰符

当请求体是 JSON（Content-Type: application/json）或字段本身是多维数组（如 user[profile][age]），input('user/a') 只能保证顶层是数组，无法递归修正子项类型。

常见错误现象：前端传 {"status":"1"}，用 input('status/d') 拿不到整型，因为 JSON 解析后字段已进入 input() 的原始数据池，修饰符只作用于一级键。

• 解决方案：先用 input('', '', 'json') 获取完整解析后的数组，再用 think\facade\Validate 或自定义函数逐层处理
• 更稳妥的做法是，在控制器开头统一调用一个清洗函数，比如 normalizeInput($this->request->param())，内部对已知字段做 intval()、array_filter()、trim() 等
• 注意兼容性：ThinkPHP 6.0+ 的 input() 对 JSON 请求默认支持，但 5.1 需手动 json_decode($this->request->getContent(), true)

别依赖“自动修复”，关键字段必须显式校验和转换

所谓智能修复只是降低低级错误概率，不是兜底机制。比如 input('price/f') 能转浮点，但不会判断是否为正数、是否超精度；input('email/s') 不会验证邮箱格式。

容易被忽略的点：input() 的默认值（第二个参数）在类型转换失败时才生效，但如果字段存在且是合法类型（如 id="0"），它就不会触发默认值，此时 0 可能被误认为“未传”。

• 数据库主键、金额、状态码这类字段，务必在业务逻辑前做二次判断：if (empty($id) || $id <= 0) { throw new ValidateException('ID 无效'); }
• 不要在模型 save() 前假设 input() 返回的已是可用数据，尤其是关联字段或 JSON 字段
• 日志中记录原始请求参数（$this->request->param()）比记录 input() 结果更有排查价值