request()->input('key', 'default') 是最稳的兜底写法,仅在键不存在或值为 null 时生效;空字符串 '' 不触发默认值,需用 filled() 或 ?? 手动判断;FormRequest 中应统一在 prepareForValidation() 中 merge 默认值。

GET 参数缺失时,request()->input() 传默认值是最直接、最可控的方式;空字符串 '' 不触发默认值,必须手动用 filled() 或 ?? 判断。
request()->input('key', 'default') 是最稳的兜底写法
它只在键完全不存在或值为 null 时生效,不会误吞合法的 0、false、''。
- 正确:
request()->input('page', 1)—— 用户没传page,或传了page=null,才用1 - 错误:
request()->input('page') ?: 1—— 传了page=0或page=''都会变成1,业务逻辑就错了 - 注意:前端传
?page=(空值),Laravel 默认转成'',不是null,所以仍不触发默认值
想覆盖空字符串?得手动判断 filled() 或 ??
当业务上认为 '' 也属于“无效输入”时,不能依赖 input() 的第二个参数,得主动干预。
request()->filled('sort') ? request()->string('sort') : 'created_at'-
$sort = $request->sort ?? 'created_at'—— 因为$request->sort在未传或为空时返回null,??才能捕获 - 别混用:
$request->input('sort') ?? 'created_at'没意义 ——input()已经返回'',??就失效了
FormRequest 中统一预填充,用 prepareForValidation()
这是集中管理默认值的最佳位置,所有验证前逻辑都收在这里,且只影响当前请求实例。
Laravel Cloud(cloud.laravel.com)。此技能用于处理所有 Laravel Cloud 请求,包括搜索和读取数据。只要任务涉及 Laravel Cloud,即使用此技能。
- 在自定义
FormRequest类里重写prepareForValidation() - 调用
$this->merge(['status' => 'draft', 'limit' => 20]),字段存在则保留原值,不存在才填入 - 避免在
rules()里写'status' => 'required|string|default:draft'——default:不是 Laravel 验证规则,会报Undefined validation rule - 如果默认值要动态计算(比如用户未传
user_id就取Auth::id()),必须放在这里做,不能靠模型层补
别指望 withDefault、default 验证规则或中间件自动兜底
这些机制根本不在 GET 参数处理链路上,强行套用只会让逻辑分散、行为不可预测。
-
withDefault()是 Eloquent 模型方法,只在create()或fill()时起作用,和请求参数无关 -
default:不是验证规则,写进rules()会被 Laravel 忽略 - 中间件不适合填默认值 —— 它执行时路由参数可能还没解析完,且无法区分“参数没传”和“参数传了但为空”
- 全局中间件或请求修改器更危险:CLI 命令、队列任务等非 HTTP 场景不会走它,导致行为不一致
真正关键的是明确每个字段的最终值来源:是来自 input() 的显式兜底,还是 prepareForValidation() 的预合并,而不是假设某处会“自动补上”。空字符串和 null 的语义差异,是绝大多数默认值逻辑出错的根源。










