“Input validation failed”并非ThinkPHP框架原始异常，而是因未正确处理validate()返回值、中间件硬编码、或统一响应层覆盖所致；应调用getError()或getErrors()获取真实错误信息。
ThinkPHP 验证失败时 Input validation failed 的真实来源
这个错误不是框架抛出的原始异常，而是你手动调用 validate() 后没处理返回值，又继续执行业务逻辑导致的。ThinkPHP 本身不会直接输出这句英文——它只在 Validate 类校验不通过时返回 false 或抛出 ValidateException，但如果你用的是 thinkphp-validation 扩展、自定义中间件或 API 统一响应层，就可能把 $validate->getError() 硬编码成固定字符串。
- 检查是否在控制器里写了类似
if (!$this->validate($data, $rule)) { throw new Exception('Input validation failed'); } - 确认是否启用了全局验证中间件（如
app/middleware/ValidateMiddleware.php），里面写了死错误信息 - 留意是否用了
think-validatev2+ 的scene模式但没定义对应场景规则，导致校验跳过却误判为失败
从 Validate 实例正确提取错误信息
ThinkPHP 6.x 的 Validate 类校验失败后，错误信息存在实例属性里，不是异常 message。直接 echo $e->getMessage() 会拿到空或默认文本，必须显式调用方法获取。
-
$validate = new Validate($rules);校验后，用$validate->getError()获取第一个错误，或$validate->getErrors()获取全部字段错误数组 - 如果用了
scene，务必先$validate->scene('login')再->check($data)，否则getError()可能为空 - 注意
getErrors()返回结构是['field' => ['error msg']]，不是扁平字符串，前端需要适配解析 - 若规则中用了
require|email|unique:user,email这类组合，getError()默认只返回第一条失败规则的提示，想看全量需遍历getErrors()
规则写法影响错误信息生成方式
ThinkPHP 的验证提示不是靠规则字符串自动翻译，而是依赖规则定义时传入的 message 参数或语言包。没配的话，默认显示“验证失败”，跟你看到的 Input validation failed 完全无关。
- 单条规则配提示：
['email' => 'require|email', 'email.require' => '邮箱不能为空', 'email.email' => '邮箱格式不正确'] - 使用语言包：在
lang/zh-cn/validate.php里定义'email' => '邮箱'和'email.require' => ':attribute 不能为空'，然后确保Lang::range('zh-cn')已生效 - 慎用闭包规则：如
['status' => function($value) { return in_array($value, [0,1]); }]，这种不会自动绑定字段名，getError()返回的是“验证失败”，无法定制提示 - unique 规则查库失败时，不触发验证错误，而是抛出
PDOException，要单独 try-catch
API 接口里避免覆盖原始错误信息
很多项目在 JsonResponse 封装层里统一返回 { "code": 400, "msg": "Input validation failed" }，等于把所有验证细节抹掉了，调试和前端体验都受损。
立即学习“PHP免费学习笔记（深入）”；
- 不要在响应构造前做字符串判断，比如
if (strpos($e->getMessage(), 'validation') !== false)就硬塞固定文案 - 推荐做法：捕获
ValidateException后，直接取$e->getError()或$e->getErrors()塞进msg或新增errors字段 - 如果用了
think-orm的模型验证，错误来自$model->validate(true)，同样要调$model->getError()，不能依赖异常 message - 前后端约定好字段级错误结构（如
{"email": ["邮箱格式不正确"]}），比笼统的“Input validation failed”有用得多
真正麻烦的从来不是写不出规则，而是错误信息被某层中间件、统一响应、日志装饰器悄悄截断或重写。盯住 getError() 的调用时机和位置，比反复改规则更关键。
