nullable仅允许字段值为null但不解决字段缺失问题，需与sometimes配合实现真正可选验证；二者协同控制“是否参与验证”和“能否接受null”两个维度。
nullable 规则只管字段值是否允许 null
nullable 的作用非常直接：它告诉验证器「这个字段可以为空（null）」，但前提是该字段**确实存在**于请求中。如果字段没传，验证器根本不会碰它——也就谈不上用 nullable 去放行。
常见错误现象是误以为加了 nullable 就能跳过缺失字段的校验，结果遇到 required 时仍报错，因为 nullable 不影响「字段是否存在」的判断。
-
nullable必须和其它规则组合使用，比如nullable|string、nullable|image - 单独写
nullable没有意义，它不提供「可选」语义，只放宽对null值的拦截 - 对文件字段特别有用：
avatar字段没上传时，Request里对应值是null，此时nullable|image才会通过
sometimes 规则决定字段是否参与验证流程
sometimes 的核心职责是「条件性启用验证」：只有当字段在请求中**实际出现**（哪怕值为空字符串、0 或 false），才去跑后续规则；如果字段压根没传，整条规则会被跳过。
典型场景是 PATCH 请求或表单部分更新——用户只改了几个字段，其他字段不该被验证器“揪出来”判空或格式错。
-
sometimes|required|string：字段存在才检查是否非空且为字符串；不存在就彻底忽略 - 和
nullable可共存，例如sometimes|nullable|json：字段传了就验证是否为合法 JSON 或null；没传就不理 - 注意陷阱：前端若传了
{"phone": ""}，phone字段「存在」，sometimes会触发，此时required仍会失败
多模态请求下两者的协同逻辑变了
Laravel 13 的多模态验证让 sometimes 和 nullable 在不同 Content-Type 下行为更一致，但也暴露了老写法的问题。比如 JSON 请求里传 {"metadata": null}，nullable|json 会通过；但若传 {}（字段完全缺失），只有 sometimes 能让它绕过验证。
- JSON API 场景推荐优先用
sometimes包裹可选字段，避免前端漏传字段导致 422 - multipart 表单中，未选择的文件输入字段在
Request中是null，这时nullable|image是刚需 - 不要混用
sometimes|required_if:other_field,1这类依赖规则时省略sometimes——否则other_field不存在时，整个条件验证链可能意外触发
更新操作中容易忽略的组合坑
在编辑用户资料时，常需要让邮箱字段「可选更新，但若传了就必须唯一且格式正确」。这时候光靠 nullable 或光靠 sometimes 都不够。
- 错误写法：
email => 'nullable|email|unique:users'—— 若请求没带email字段，验证器不报错；但若带了email: null，unique仍会查库，可能误判 - 正确写法：
email => 'sometimes|nullable|email|unique:users,email,except,id'—— 字段存在才验证，允许null，且更新时排除自身 ID - 关键点：
sometimes控制「是否进验证管道」，nullable控制「管道里能否接受null」，except控制「唯一性查库范围」——三者缺一不可
{"status": "null"}（字符串）还是 {"status": null}（JSON null），Laravel 解析后类型不同，nullable 生效前提就变了。这种时候得配合 transform 或中间件预处理，不能只押注验证规则。 
