request()->get()传默认值最直接，适用于绝大多数GET参数场景，不抛异常、语义清晰、兼容5.5+；路由查询参数无法设默认值，须在控制器中处理；表单验证前需先设默认值；注意空字符串等假值不触发默认，需显式类型转换。
request()->get() 传第二个参数设默认值最直接
绝大多数 GET 参数取值场景，用 request()->get() 并传入默认值是最稳妥的方式。它不会抛异常，也不会因键不存在而报 Notice，语义清晰且兼容 Laravel 5.5+ 所有版本。
常见错误是误用 request()->input() 后手动判空——其实两者行为一致，但 get() 更明确表达“尝试获取”，且在 IDE 中提示更友好。
-
request()->get('page', 1)：当 URL 没带page或值为空字符串时，返回1 -
request()->get('search', '')：显式兜底空字符串，避免后续trim()报错 - 注意：
request()->get('filter', [])若期望数组类型，默认值必须是数组，否则后续foreach会出错
路由参数里不能直接设默认值，得靠可选参数 + 中间件或控制器逻辑兜底
Laravel 路由定义（如 Route::get('posts/{id?}', ...)）只支持路径参数的可选性，不支持查询参数（即 ?key=value 部分）设默认值。试图写成 /posts?id={id?} 是无效的，URL 查询参数永远由请求动态决定。
所以真正需要默认行为的 GET 查询参数，必须在进入控制器后处理：
- 在控制器方法开头统一调用
request()->merge(['sort' => request()->get('sort', 'created_at')])，后续所有request()->get('sort')都已带默认值 - 若多处用到同一组默认逻辑，抽成一个私有方法，比如
resolveListParams()，返回带默认值的参数数组 - 别在中间件里盲目
request()->merge()，除非确认该默认值对所有路由都适用；否则容易污染其他接口的原始参数
表单验证时 required_if 等规则和默认值要分开处理
很多人以为给验证规则加 'field.*' => 'required_if:other_field,1' 就能自动补默认值——其实不会。required_if 只控制是否校验，不提供赋值能力。参数缺失时验证器仍收到 null 或空字符串，导致校验失败或逻辑错乱。
正确做法是先取默认值，再进验证流程：
$data = request()->only(['status', 'category']);
$data['status'] = request()->get('status', 'draft'); // 先设默认
$validated = Validator::make($data, [
'status' => 'required|in:draft,published,archived',
'category' => 'nullable|exists:categories,id'
])->validate();
- 不要把
request()->get()嵌在验证规则数组里（如'status' => 'required|in:' . request()->get('status', 'draft')），规则字符串是静态解析的，运行时取不到 - 如果用 Form Request 类，建议在
prepareForValidation()里做默认值合并，比在rules()里硬拼更安全
注意空字符串、'0'、'false' 这些“假值”会被 get() 当作存在值处理
request()->get('flag', true) 在 URL 是 ?flag=0 时返回字符串 '0'，不是布尔 false，更不是默认值 true。这是最容易被忽略的隐式类型陷阱。
如果你的业务逻辑依赖布尔含义（比如开关），必须显式转换：
- 用
filter_var(request()->get('active'), FILTER_VALIDATE_BOOLEAN)处理1/0/on/off/true/false等常见布尔表示 - 或封装一个助手函数：
bool_input('active', true)，内部做类型归一化 - 数据库查询中直接用
where('is_active', request()->get('active', 1))很危险——'0'字符串和整数0在某些驱动下可能不等价
默认值机制本身很简单，难的是判断哪些参数真需要默认、默认成什么类型、以及怎么让后续所有代码都按这个默认预期工作。漏掉类型转换或混用空值判断，往往比没设默认值还难排查。
