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()结果更有排查价值
