推荐用$request->input()取get参数，它统一处理query/body/route，支持默认值和类型转换；避免直接用$_get或request()->query()导致null异常或类型错误。
GET参数怎么从 request 对象里取出来
直接用 request()->query 或 request()->get() 都可以，但推荐用 request()->input() —— 它统一处理 query、body、route 参数，且支持默认值和类型转换。
常见错误是写成 request()->query('page') 却没传 page，结果返回 null 而不是你想的 1；或者用 request()->get('page') 时传了字符串 "1"，后续做数学运算出错。
-
request()->input('page', 1)：没传时默认为整数1 -
request()->integer('page', 1)：强制转为 int，传page=1.5会变成1 -
request()->filled('search')判断是否非空（排除""、null、0等 falsy 值） - 别用
$_GET，绕过 Laravel 的过滤和验证逻辑，容易漏掉 XSS 或类型隐患
带数组的 GET 参数（如 ?tags[]=php&tags[]=laravel）怎么解析
Laravel 默认支持 PHP 风格的数组查询参数，但必须命名带 []，否则 request()->input('tags') 只拿到最后一个值。
比如请求 /api/posts?tags=php&tags=laravel → input('tags') 是字符串 "laravel"；而 /api/posts?tags[]=php&tags[]=laravel → 才是数组 ['php', 'laravel']。
- 前端发请求时确保 key 名带
[]，axios 默认不加，要手动拼或用URLSearchParams -
request()->array('tags')可强制返回数组（即使只传一个值也包装成['php']） - 验证规则里写
'tags.*' => 'string|min:2'，而不是'tags' => 'array'，否则校验不到每个元素
中文或特殊字符参数乱码或 400 错误
本质是 URL 编码问题。Laravel 本身不干预解码，但如果你在 Nginx/Apache 或浏览器层没正确处理 UTF-8，就会出现 %E4%BD%A0%E5%A5%BD 解不出来、或直接 400 Bad Request。
- 确认前端用
encodeURIComponent('你好')编码，而不是encodeURI（后者不编码/ ? &） - Nginx 配置里加
charset utf-8;，避免响应头缺失导致浏览器误判 - 如果用了 API 网关或 CDN，检查它是否对 query string 做了二次 decode 或截断（常见于含
+或空格的参数） - Laravel 日志里看到
InvalidArgumentException: Malformed UTF-8 characters，大概率是某层提前 decode 过一次，再被 PHP 自动 decode 就崩了
如何批量校验和过滤 GET 参数
别在控制器里一个个 input() + if 判断，用 validate() 方法最稳，而且能自动返回 422 和标准错误结构。
注意：GET 请求的验证规则和 POST 几乎一样，但 required 表示“必须出现在 URL 中”，不是“不能为空”——想允许缺失但有值才校验，得用 nullable 或 sometimes。
$validated = request()->validate(['page' => 'integer|min:1', 'search' => 'nullable|string|max:50']);-
'search' => 'sometimes|string|min:2'：只在校验时存在该参数才触发规则 - 过滤建议用
request()->only(['page', 'limit', 'sort'])，比手写array_filter更安全 - 如果参数名是动态的（比如字段名来自用户输入），务必白名单过滤，禁止直接进
orderBy($field)
实际项目里，GET 参数看似简单，但边界情况多：空字符串 vs null、编码嵌套、数组格式歧义、验证时机早于中间件……这些地方一松懈，就容易漏掉日志、返回错状态码，或者让前端反复重试失败请求。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
