required_with仅校验字段存在时是否非空，不检查字段是否存在；需双向required_with或闭包规则实现互为依赖，嵌套结构中需避免点语法失效，PATCH场景需配合filled/present。
required_with 规则不校验字段是否存在，只校验“存在时是否非空”
很多人以为 required_with 是“当 A 存在时，B 必须存在”，其实不是。它只检查 B 是否被传入且值不为空（即非 null、非空字符串、非空数组等）。如果 B 字段压根没出现在请求体里，required_with:A 直接跳过，不会报错。
常见错误现象：{"a": "foo"} 通过了校验，但业务上你其实期望 B 也必须提供。
- 真正需要“互为依赖”时，得组合用
required_if或required_unless - 若 A 和 B 必须同时出现或同时不出现，用
required_with+required_without配对 - Laravel 9+ 支持闭包规则，可写更精确逻辑，比如
function ($attribute, $value, $fail) { ... }
两个字段互为依赖：A 有则 B 必须有，B 有则 A 必须有
这是最典型的“互斥/共存”场景。不能只靠一个 required_with，必须双向约束：
-
'a' => 'required_with:b'→ B 存在时，A 必须存在且非空 -
'b' => 'required_with:a'→ A 存在时，B 必须存在且非空 - 但注意：如果两者都缺失，整组校验仍会通过 —— 这是 Laravel 默认行为，符合“required_* 系列只管‘有则必有效’”的设计哲学
- 若要强制“两者必须同时存在或同时不存在”，加一条自定义规则：
'a,b' => 'required_with_all:a,b|prohibited_if:a,null|prohibited_if:b,null'不推荐，太绕；更干净的做法是写个闭包
required_with 在嵌套数组或 JSON 请求体里容易失效
当请求体是 {"user": {"name": "x", "phone": "123"}} 这类结构时，required_with:user.phone 不起作用 —— Laravel 的 dot notation 对嵌套数组支持有限，尤其在 JSON body 中，required_with 只认顶层键名。
- 正确做法：用
required_with:user检查整个user数组是否存在，再在user.*下单独定义子规则 - 或者把校验逻辑提到控制器里，用
$request->validate()分两步：先校验顶层结构，再对$request->user单独 validate - 别指望
required_with:user.phone能触发 —— 它会静默忽略，不报错也不生效
和 required_if 混用时，注意条件判断的“真值”边界
required_if 看的是字段值是否“等于指定值”，而这个“等于”是松散比较（==），不是严格（===）。比如 required_if:status,active，当 status 是整数 1 或字符串 "1"，都不会触发 —— 但如果是字符串 "active" 或布尔 true（且表单提交为 active），就会触发。
- 常见坑：前端传
{"status": 1}，后端规则写required_if:status,active，结果永远不校验 B 字段 - 安全做法：统一用字符串传参，或改用闭包规则做严格判断：
function ($attribute, $value, $fail) use ($request) { if ($request->status === 'active') { ... } } - 性能影响几乎为零，但可读性和可控性明显提升
最常被忽略的一点：Laravel 的验证规则默认不处理“字段未传 vs 字段传了但为 null”的区别。如果你的 API 允许 PATCH 部分更新，又依赖字段存在性做逻辑分支，光靠 required_with 是不够的 —— 得配合 filled、present 或显式检查 $request->has('field')。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
