$request->validate() 中仅用 required|string|email 不够严格，因 required 不过滤空白字符（如全角空格、BOM），需组合 trim 及 Unicode 正则；unique 存在大小写敏感、NULL 绕过和字段名注入风险；API 场景下需捕获 ValidationException 自定义响应结构，避免依赖默认 JSON；自定义 Rule 类须防内存泄漏，禁用构造函数缓存与未过滤数据访问。
直接在 $request->validate() 里加 required|string|email 这类规则，根本达不到“严格验证”效果——它只做基础格式检查，不防空格、不校验 Unicode、不处理多字节截断、也不拦截恶意 payload。真要严格，得组合规则、控制上下文、干预底层行为。
为什么 required 不等于“非空字符串”
required 只判断值是否为 null、'' 或未提交，但对 "\t\n "、" "（全角空格）、"\u{FEFF}"（BOM）完全放行。这类数据进数据库后可能引发唯一索引冲突或前端渲染异常。
- 必须搭配
trim规则：如'email' => 'required|trim|email' - 若用
Validator::make()，需手动调用$request->except('') → array_map('trim', ...)预处理 -
trim不处理 Unicode 空格（如 U+3000），需额外加regex:/^[^\p{Z}]+$/u（需启用 PCRE Unicode 支持）
unique 规则的三个隐藏陷阱
unique:users,email 看似安全，但默认忽略大小写、不处理 NULL 值、且不防 SQL 注入式字段名。
- 大小写敏感问题：MySQL 默认
utf8mb4_unicode_ci排序规则下，foo@ex.com和FOO@EX.COM被判重复；应显式加lower或改用whereRaw('LOWER(email) = ?', [strtolower($value)]) - NULL 值绕过：数据库中多条
email=NULL记录，unique检查会全部通过；需配合nullable+ 自定义逻辑排除 NULL - 字段名注入风险：若表名/字段名来自用户输入（如动态路由参数），必须白名单校验，禁止直接拼接进
unique:{$table},{$column}
API 场景下 validate() 的响应体不可信
当请求头含 X-Requested-With: XMLHttpRequest 或 Accept: application/json 时，Laravel 自动返回 JSON 错误，但字段名和消息结构固定，无法按 API 规范定制（如要求 errors.[].field 而非 message）。
- 不能依赖自动响应，应捕获
ValidationException并重写：try { $request->validate([...]); } catch (ValidationException $e) { return response()->json([ 'code' => 422, 'errors' => collect($e->errors())->mapWithKeys(fn($msgs, $field) => [$field => $msgs[0]]) ], 422); } -
withErrors()在 API 中无意义，仅对 Web 重定向有效 - 若用 Form Request，需重写
failedValidation()方法，否则仍走默认逻辑
自定义 Rule 类如何避免内存泄漏
用 php artisan make:rule ValidPhoneNumber 生成的类，若在 passes() 中调用 Eloquent 查询或加载大文件，会在每次验证时重复执行，且无法被容器释放。
- Rule 类实例生命周期绑定单次请求，但内部状态不会自动清理；避免在
__construct()中缓存 DB 连接或静态数组 - 需访问请求全部数据时（如跨字段比对），不要在
passes()里调用$this->validator->getData()—— 它返回原始未过滤数据，可能含恶意键名 - 真正严格的手机号验证，应结合运营商号段库（如
overtrue/phonenumber），而非仅靠正则；Rule 类里用static $cache = [];缓存号段数据，并设 TTL
严格验证不是堆砌规则，而是清楚每个规则的边界在哪、谁控制底层行为、错误由谁最终呈现。Laravel 的验证器是管道，不是黑盒——你得知道水从哪进、在哪被过滤、渣子沉在哪。
