用 request 类获取当前完整 url 应直接调用 fullurl()，它返回含协议、域名、路径及完整查询参数的 url；url() 仅返回根 url（不含查询参数）；fullurlwithquery() 可追加或覆盖查询参数。
怎么用 Request 类获取当前完整 URL
直接调 url() 或 fullUrl() 就行，别绕去拼接 $_SERVER。前者是 Laravel 封装好的可靠方式，后者会漏掉查询参数或出编码问题。
常见错误是写 request()->getRequestUri() —— 它只返回路径 + 查询字符串，不带协议和域名，拼起来容易错。
-
url()：返回当前请求的根 URL（不含查询参数），比如https://example.com/admin -
fullUrl()：返回带协议、域名、路径和完整查询参数的 URL，比如https://example.com/search?q=laravel&sort=desc -
fullUrlWithQuery(['page' => 2])：在当前 URL 基础上追加/覆盖查询参数，适合分页链接生成
在控制器里怎么安全地拿到当前 URL
别用 $_SERVER['REQUEST_URI'] 或手拼 $_SERVER['HTTP_HOST']，这些在反向代理、HTTPS 卸载、CLI 测试环境下极不可靠。
推荐两种写法，按场景选：
- 在控制器方法参数里类型提示
Illuminate\Http\Request：最清晰，依赖明确，测试友好 - 用门面
request()：方便但隐藏了依赖，单元测试时要 mock，适合快速脚本类逻辑
示例：
public function index(Request $request)
{
$current = $request->fullUrl(); // ✅ 推荐
// $current = request()->fullUrl(); // ✅ 也可，但不如上者显式
}
fullUrl() 和 url() 的协议/端口兼容性差异
两者都依赖 APP_URL 配置和服务器真实头信息，但行为不同：
-
url()优先读APP_URL，没设就 fallback 到请求头里的Host+ 当前协议；它**忽略端口**（除非是非标准端口且显式配置了APP_URL） -
fullUrl()更“诚实”，会从$_SERVER中提取原始协议（HTTPS是否存在）、端口（SERVER_PORT）、主机（HTTP_HOST或SERVER_NAME），所以反向代理没配好时可能返回http://而不是实际访问的https://
如果你的应用跑在 Nginx + HTTPS 卸载环境下，必须确保 TrustedProxy 中间件已启用，并配置了正确的 TRUSTED_PROXIES，否则 fullUrl() 会误判协议。
为什么不能在 Blade 模板里直接写 request()->fullUrl()
能运行，但不推荐——模板层不该承担 URL 构建逻辑，尤其涉及动态参数时容易失控。
更合理的方式是控制器提前算好传入：
- 只读展示当前地址：传
$currentUrl = $request->fullUrl() - 要生成带参数的新链接：用
$request->fullUrlWithQuery(...)算好再传，避免模板里重复逻辑 - 需要多处复用：封装成一个辅助函数或 View Composer，而不是在每个
@if里调request()
另外注意：Blade 缓存后，request() 在缓存生命周期内不会刷新，可能导致 URL “冻住”——这在重定向、A/B 测试等场景下很危险。
fullUrl() 对 X-Forwarded-Proto 的依赖，经常被当成“理所当然”而跳过中间件配置。
