Webman需手动配置全局异常处理器并正确解析请求体才能实现统一参数校验与JSON响应：在Handler.php中分别捕获BusinessException和Throwable，返回标准code/msg结构；同时用getRequestBody()提取JSON数据，将验证规则抽离为配置数组。
Webman 本身不提供开箱即用的统一参数校验 + 全局异常响应机制，直接写 if 判断或抛 Exception 会导致 Uniapp 等前端收不到 code/msg 结构，而是拿到 500 HTML 页面或空响应。
Webman 的 validate 报错默认返回 HTML 或堆栈，不是 JSON
这是最常踩的坑：你用了 Validator::make($data)->required('email')->email('email')，但没配异常捕获，一旦失败，Webman 就直接输出 PHP 错误页（或空白），Uniapp 的 fail 回调里看到的是 statusCode: 500 或网络超时，完全不知道哪条规则没过。
- 根本原因：Webman 默认没注册全局异常处理器，
ValidatorException没被拦截 - 验证器本身不决定响应格式，它只负责“抛”；响应结构由异常处理层决定
- 哪怕你用的是
jeckleee/tools或FormValidator，只要没配好顶层兜底，就一定会掉进这个坑
必须手动注册全局异常处理器，且要区分业务异常和系统异常
不能只 catch ValidatorException，否则 DB::insert() 失败、Redis 连接超时等照样返回 500 页面。得在 app/exception/Handler.php 里统一接管：
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 捕获
\support\exception\BusinessException（业务校验失败）→ 返回json(['code'=>400, 'msg'=>$e->getMessage(), 'data'=>[]]) - 捕获
\Throwable（所有未预期错误）→ 记录日志 + 返回json(['code'=>500, 'msg'=>'服务器内部错误'])，生产环境绝不能暴露堆栈 - 特别注意：不要在中间件里 try-catch 所有逻辑，会掩盖真实错误位置；Handler.php 是唯一正统入口
参数校验必须和请求体解析强绑定，尤其对 Uniapp
Uniapp 发送 JSON 数据时，$request->post() 拿不到字段——它只解析 application/x-www-form-urlencoded。不处理这点，校验永远跑在空数组上。
- 务必先用工具函数提取真实数据：
getRequestBody($request)，内部判断content-type后调用$request->json()或$request->post() - 校验前检查
is_array($data) && !empty($data)，避免传 null 给Validator::make()导致静默失败 - 如果用
FormValidator，它的$request->all()默认行为不可靠，必须重写构造函数，显式传入getRequestBody($request)结果
别迷信“链式验证器”，复杂场景下规则复用才是关键
写 Validator::make($data)->required('a')->required('b')->strLength('c', 2, 10) 看似简洁，但一到多接口共用同一套规则（比如注册 + 修改资料），就会重复粘贴、改漏字段、难维护。
- 把规则抽成配置数组，存在
config/validate/user.php里，按场景分组：'register' => [...],'update' => [...] - 控制器里只写
Validator::make($data)->rules(config('validate.user.register'))，一行切换规则集 - 自定义规则（如“手机号已存在”）必须用闭包 + DB 查询，但闭包里别写
throw new BusinessException，而应返回字符串错误信息，让验证器统一抛出
真正难的不是写几行校验代码，而是让每种错误都落到可预测的 code 字段里，并确保前端能靠这个字段做精准提示。只要 Handler.php 没配稳、请求体没解析对、规则没抽离，再漂亮的链式语法都是空中楼阁。
