Laravel 的 uuid 规则仅校验 RFC 4122 字符串格式，不验证版本与变体；需用 uuid_v4 自定义规则确保 v4 合法性，并配合 required|string 防空值跳过，同时注意数据库字段类型与校验逻辑对齐。
用 uuid 规则校验字段是否为 RFC 4122 格式
Laravel 的 uuid 验证规则默认只检查字符串是否符合 RFC 4122 定义的 UUID 字符串结构（如 550e8400-e29b-41d4-a716-446655440000），不验证版本号或变体位，也不做实际解析。它本质是正则匹配：/^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i。
实操建议：
- 直接在请求验证规则中写
'id' => 'required|uuid'即可，无需额外引入包 - 该规则对
nil UUID（00000000-0000-0000-0000-000000000000）也通过，若业务不允许，需额外加not_in:00000000-0000-0000-0000-000000000000 - 注意：Laravel 9+ 才支持带版本前缀的
uuid:v4等细化规则；旧版本只能靠自定义规则或正则
自定义 uuid_v4 规则确保版本和变体合法
原生 uuid 不校验版本号（如 v1/v4）和变体（variant），而 RFC 4122 要求 v4 UUID 第13位是 4、第17位是 8|9|a|b。线上曾有用户传入伪造的 xxxxxxxx-xxxx-3xxx-xxxx-xxxxxxxxxxxx（v3）通过校验，导致下游解析失败。
实操建议：
- 在
App\Providers\AppServiceProvider::boot()中注册自定义规则：Validator::extend('uuid_v4', function ($attribute, $value, $parameters, $validator) { if (! is_string($value) || ! preg_match('/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i', $value)) { return false; } return true; }); - 使用时写
'id' => 'required|uuid_v4' - 不要依赖
Str::isUuid()—— 它只做基础格式检查，和原生uuid规则行为一致
API 请求体中 UUID 字段为空字符串或 null 导致校验跳过
常见错误现象："id": "" 或 "id": null 传入后，uuid 规则不报错。这是因为 Laravel 默认把空字符串和 null 当作“缺失字段”，而 required 未触发时，后续规则被跳过。
实操建议：
- 必须显式加
filled或required|string前置约束：'id' => 'required|string|uuid' - 若允许空值但需区分语义，改用
nullable|uuid，并自己处理空逻辑 - 前端传
null时，Laravel 默认会把它转成 PHPnull，此时string规则会失败，这是预期行为
数据库字段类型与 UUID 校验不匹配引发隐性问题
即使 API 层校验通过，如果数据库字段是 CHAR(36) 但没设 utf8mb4_bin 排序规则，大小写混用（如 A 和 a）可能被当作不同值；更糟的是，用 BINARY(16) 存储但 API 仍传字符串，会导致查询失效。
实操建议：
- 校验通过 ≠ 存储安全，务必确认迁移文件中字段定义与校验逻辑对齐：
$table->uuid('id')->primary(); // Laravel 9+ 原生支持 - 若用字符串存储，推荐
CHAR(36) COLLATE 'utf8mb4_bin'，避免大小写归一化 - 别在验证规则里写死长度（如
size:36），UUID 字符串固定 36 字符，但uuid规则已覆盖，重复限制无意义
真正容易被忽略的是：校验只发生在应用层，中间件、队列任务、API Gateway 后的二次转发都可能绕过它。如果服务暴露给不可信调用方，得在最外层网关或反向代理上加一层正则过滤，不能只信 Laravel 的 Request 验证。
