JWT字段校验需在auth:api基础验证后手动实现，推荐使用Request类或Policy处理，通过auth()->payload()安全提取payload并校验字段存在性、类型及值，避免直接base64_decode或硬编码中间件逻辑。
JWT字段校验该用哪个中间件
Laravel本身不内置JWT字段级校验逻辑，auth:api中间件只负责解码并验证签名和过期时间，不会检查payload里某个字段是否存在、是否为字符串、是否匹配正则等。真要校验user_role或scope这类自定义字段，得自己写逻辑。
常见错误是以为加了auth:api就万事大吉，结果攻击者伪造一个合法签名但篡改is_admin为true，后端直接信任使用——这恰恰是因为没做字段级校验。
- 用
Auth::user()拿到的是解码后的数组/对象，字段校验必须在这之后手动做 - 别在中间件里硬塞太多业务逻辑，建议拆到Request类或Policy中
- 如果用
tymon/jwt-auth，注意v1.x和v2.x的getPayload()返回类型不同：v1返回JWTToken对象，v2返回array
如何安全提取并验证JWT中的字段
不能直接$request->bearerToken()然后base64_decode——签名会失效，且无法防篡改。必须走JWT库的验证流程，确保alg、signature、exp全通过，再读payload。
示例场景：API要求请求头带Authorization: Bearer xxx，且payload中必须有app_id且值为"web-v2"：
// 在控制器方法里
$payload = auth()->payload(); // tymon/jwt-auth v2+
if (!isset($payload['app_id']) || $payload['app_id'] !== 'web-v2') {
abort(403, 'Invalid app_id in token');
}
-
auth()->payload()只在token已通过基础验证后可用，否则抛Tymon\JWTAuth\Exceptions\TokenInvalidException - 不要用
json_decode(base64_decode(...))手动解析header/payload，跳过签名验证等于裸奔 - 字段值比较前务必用
trim()和is_string()兜底，避免空格或null绕过
签名有效但结构异常怎么捕获
JWT签名正确，但payload里缺字段、类型错（比如user_id是数组不是整数）、JSON格式损坏——这些auth:api中间件完全不管，得靠后续代码显式检查。
典型错误现象：Trying to access array offset on value of type null，因为假设$payload['user_id']一定存在，实际是undefined index。
- 用
data_get($payload, 'user_id')比直接$payload['user_id']更安全 - 对关键字段做类型断言：
is_int(data_get($payload, 'user_id'))，别信文档说“一定是int” - 如果用Laravel 9+，可配合
validated()方法在FormRequest里统一约束：$this->safe()->user_id->integer() - 注意
iat、nbf等标准字段也可能被恶意设为非整数，导致Carbon::createFromTimestamp()报错
多签发源场景下字段校验容易漏什么
当APP、小程序、后台管理共用同一套JWT密钥，但各自签发的token payload结构不一致（比如小程序带open_id，后台带permissions），字段校验逻辑很容易一刀切出错。
例如：给小程序签发的token没permissions字段，但校验逻辑强制要求它存在——结果所有小程序请求403。
- 按
aud（audience）或iss（issuer）分流校验规则，而不是全局一套if (isset($p['permissions'])) - 用
auth()->getPayload()->get('iss')识别来源，再加载对应规则集 - 别把字段校验写死在中间件里，否则新增一个客户端就要改核心中间件
- 测试时一定要用真实签发流程生成token，别用
JWTFactory::make([...])手动生成payload绕过签名环节
最麻烦的其实是调试：token看着合法，但某个字段值是空字符串或全角数字，肉眼难发现。抓包看原始Authorization头，用jwt.io手动粘贴验证，比在代码里dump快得多。
