应优先用 $_SERVER[‘REQUEST_SCHEME’] 判断协议，再拼接 $_SERVER[‘http_HOST’] 与 $_SERVER[‘REQUEST_URI’]，端口仅在非80/443时显式添加；laravel中request()->fullUrl()返回完整绝对URL，url()->current()仅返回路径级URL。
PHP 中 $_SERVER 获取当前 URL 的常见误区
直接拼 $_SERVER['HTTP_HOST'] + $_SERVER['REQUEST_URI'] 看似简单，但容易漏掉 https 判断和端口异常。比如 nginx 反向代理后 $_SERVER['HTTPS'] 可能为空，$_SERVER['SERVER_PORT'] 也不反映真实访问端口。
- 优先用
$_SERVER['REQUEST_SCHEME']（PHP 5.6+），它比检查$_SERVER['HTTPS'] === 'on'更可靠 - 如果端口不是 80 或 443，才显式拼入
:<code>$_SERVER['SERVER_PORT']，否则 URL 会多出冗余端口 -
$_SERVER['REQUEST_URI']包含查询参数，但不带域名；若需完整 URL，必须自己拼接协议 + 域名 + 路径
Laravel 控制器里用 request()->fullUrl() 还是 url()->current()
request()->fullUrl() 返回带全部查询参数的完整 URL，url()->current() 只返回路径 + 查询参数，不含域名和协议。选哪个取决于你是否需要在邮件、跳转链接等场景生成可直接访问的绝对地址。
- 做分享链接、重定向目标、日志记录原始请求时，用
request()->fullUrl() - 只比对当前路由或做前端高亮时，
url()->current()更轻量，且不受代理头污染 - 注意：如果应用部署在子目录（如
/app/），url()->current()默认包含子目录前缀，request()->fullUrl()不包含——这取决于APP_URL和服务器配置是否一致
Node.js express 中 req.protocol 和 req.originalUrl 的可靠性
req.protocol 默认只读取 req.headers['x-forwarded-proto']，没配反向代理时永远是 http；req.originalUrl 是原始请求路径，但可能被中间件修改（比如 app.use('/api', router) 后它仍含 /api）。
- 必须在入口处信任代理：设置
app.set('trust proxy', true)，否则req.protocol和req.ip都不可信 - 要获取“用户实际看到的 URL”，组合用
req.protocol + '://' + req.get('host') + req.originalUrl - 如果用了 URL 重写（如 Nginx 的
rewrite ^/v1/(.*)$ /$1 break;），req.originalUrl仍是/v1/xxx，此时得靠req.url（已被重写后的路径）
Python flask 中 request.url vs request.base_url 的参数处理差异
request.url 是完整 URL（含查询参数），request.base_url 是不带查询参数的地址。但很多人忽略：当使用 WSGI 中间件（如 ProxyFix）或部署在非根路径时，两者都可能出错。
- 没启用
ProxyFix时，request.url的协议和 host 来自 WSGI 环境变量，常为http://localhost:5000，而非真实访问地址 - Flask 2.2+ 推荐用
request.url+request.environ.get('HTTP_X_FORWARDED_PROTO')手动修正，而不是依赖旧版request.url_root - 若需拼接新参数（比如分页加
?page=2），别直接字符串拼request.url + '&page=2'，先用urllib.parse.urlparse()解析再重建，避免重复问号或编码错误
URL 拼接这件事，表面是字符串操作，实际是信任链问题：你信的是客户端 header，还是反向代理，还是框架封装？参数解析同理——看似 request.query 就能拿，但编码、数组格式、空值处理全在细节里。这些地方不测真实部署环境，本地永远没问题。