嵌套字段校验需先确保父级存在且为数组，如address需加required|array；数组型嵌套用contacts.*前应先校验contacts→required|array|min:1；sometimes对深层字段无效，应改用required_if或自定义规则；取值时用data_get或validated()配合array校验更安全。
如何用 required_if 和 array 验证嵌套字段存在性
嵌套字段校验失败，往往不是规则写错了，而是没告诉 Laravel “这层结构本身得先存在”。比如 address.street 要校验，但 address 是个空字符串或 null，Laravel 会直接跳过子字段——它连数组都不是，自然不往下钻。
必须显式要求父级是数组：
-
address字段加required|array - 再写子字段规则，如
address.street→required|string - 如果
address是可选的，但一旦出现就要校验内部，改用required_if:address,!=,null+array组合（注意：Laravel 9+ 支持required_if:address,exists这类更准的判断）
用点号写规则时，.* 和 .0 的区别在哪
面对数组型嵌套（比如多个联系人），contacts.*.email 是通用写法，但容易忽略两点：一是 .* 不校验数组是否为空；二是某些版本对稀疏索引（如 [1, 3]）行为不一致。
更稳的做法：
- 先用
contacts→required|array|min:1确保非空且是数组 - 再用
contacts.*.email→required|email校验每个元素 - 如果必须按顺序校验（比如第 0 个是主联系人），改用
contacts.0.email，避免.*匹配到意外键名（如contacts.foo） - Laravel 10 默认启用严格数组模式，
.*只匹配数字索引；若传了字符串键，需显式用contacts.*.key或改用each规则
sometimes 在嵌套场景下为什么常失效
sometimes 的逻辑是“仅当请求中存在该字段才校验”，但它只检查顶层键。比如传了 {"user": {"name": ""}}，user.name 规则带 sometimes，Laravel 并不会触发——因为 user.name 这个键根本没出现在原始请求里，它只是 user 数组里的一个属性。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
真正需要的是条件校验：
- 用
required_if:user,!=,null替代sometimes对子字段的依赖 - 或者把整个嵌套结构收进一个自定义验证规则，用
$data['user'] ?? null手动判断再抛异常 - 别在
user.*上加sometimes，它对深层字段无效
验证后取值时，$request->input('user.name') 返回 null 的常见原因
规则通过 ≠ 数据能取到。最常踩的坑是：前端传了 {"user": null} 或 {"user": ""}，Laravel 解析后 $request->input('user.name') 必然为 null，哪怕你写了 user.* 规则。
安全取值方式：
- 不用
$request->input('user.name')，改用data_get($request->all(), 'user.name')（自动处理空数组/空对象） - 或提前 cast：
$request->validated()['user']['name'] ?? null—— 但前提是user已通过array校验，否则会报错 - 调试时 dump
$request->all()，确认实际结构，别只信文档或前端口头承诺
嵌套校验真正的复杂点不在语法，而在「请求数据的结构真实性」——Laravel 按 PHP 数组模型解析 JSON，但前端可能传任意形状的数据，包括 null、""、{}、[]，它们在 PHP 里行为完全不同。校验规则得和这些边界情况一一对应上，不能只盯着字段名写点号。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
