Go 解析相对请求目标失败怎么办

Go 用 url.ParseRequestURI 解析 catalog/items?page=2 失败，通常不是少写了协议，而是把“相对引用”当成了“HTTP 请求目标”。无前导斜线的相对引用可交给 url.Parse；普通请求路径应形如 /catalog/items?page=2；需要发起 HTTP 请求的配置地址则还要有合适的 scheme 和 host。

不要在错误后自动补 https:// 或 /：它们会改变输入含义。先确定调用方传来的究竟是什么，再选择解析器和业务约束。Go 官方接口说明：https://pkg.go.dev/net/url#ParseRequestURI。

先辨认输入属于哪种地址

网关路由、页面链接和上游服务配置常被塞进同一个名为 url 的字符串字段，但三者并不等价。路由需要路径与查询；页面链接可能相对于当前目录；上游服务配置通常需要完整 HTTP 地址。若接口不说明输入契约，下游只能猜测，修复往往变成不断加前缀。

这里“绝对路径”只指以斜线起始的 URI 路径，不表示它已经包含域名，更不是操作系统文件路径。url.Parse 接受相对引用，也不等于解析结果可以直接交给 HTTP 客户端访问。

ParseRequestURI 不接受任意相对引用

ParseRequestURI 按 HTTP 请求中的输入解释字符串，接受绝对 URI 或绝对路径，而不是任意相对路径。因而 catalog/items 不属于它的一般路径输入范围；/catalog/items 则表达从根开始的路径。选用哪个形式，应由业务定义决定，不能为了消除错误随意改写。

它也不是“必须包含域名”的校验器：/catalog/items 成功解析时 Host 仍然为空。反方向也一样，IsAbs 只判断是否有 scheme，不能据此证明是可用的 HTTP 服务地址。更不能用解析成功证明远端存在。

把解析与HTTP地址要求分开

下面三个小函数分别保留各自契约。第一个函数主动限制为单斜线路径，第二个只做通用引用解析，第三个要求适合作为配置项的 HTTP 绝对地址。它们均不发送网络请求。代码未在本文执行，示例判断属于接口语义说明。

package addressparse

import (
    "fmt"
    "net/url"
    "strings"
)

// ParsePathTarget 只接收业务约定的单斜线请求路径，可带查询串。
func ParsePathTarget(raw string) (*url.URL, error) {
    if !strings.HasPrefix(raw, "/") || strings.HasPrefix(raw, "//") {
        return nil, fmt.Errorf("需要单斜线开头的请求路径")
    }
    if strings.Contains(raw, "#") {
        return nil, fmt.Errorf("请求路径不接收未转义的片段标记")
    }
    u, err := url.ParseRequestURI(raw)
    if err != nil {
        return nil, fmt.Errorf("解析请求路径: %w", err)
    }
    return u, nil
}

// ParseReference 接收相对引用；并不自动补成可请求的绝对地址。
func ParseReference(raw string) (*url.URL, error) {
    u, err := url.Parse(raw)
    if err != nil {
        return nil, fmt.Errorf("解析地址引用: %w", err)
    }
    return u, nil
}

// ParseHTTPAddress 为配置项添加HTTP地址约束，不做网络连接。
func ParseHTTPAddress(raw string) (*url.URL, error) {
    u, err := url.Parse(raw)
    if err != nil {
        return nil, fmt.Errorf("解析配置地址: %w", err)
    }
    // IsAbs只说明有scheme，不能替代HTTP地址结构要求。
    if (u.Scheme != "http" && u.Scheme != "https") ||
        u.Hostname() == "" || u.Opaque != "" || u.User != nil ||
        strings.Contains(raw, "#") {
        return nil, fmt.Errorf("需要不含用户信息和片段的HTTP绝对地址")
    }
    return u, nil
}

ParsePathTarget 对双斜线与原始井号的限制是本例业务约定，不要说成 ParseRequestURI 自身必然拒绝它们。ParseHTTPAddress 也只是起点：它不检查 DNS、端口可达性或目标是否获准访问，不能作为完整的目的地址安全策略。

当调用方明确要支持目录相对引用时，可以先 url.Parse，再对可信基础 URL 调用 ResolveReference。基础路径是否以斜线结尾会影响目录语义；这不是字符串相加。不要在只要求固定上游主机的配置接口里，悄悄允许任意 scheme 或 host 覆盖。

网关收到的字段不等于出站URL

在 net/http 的服务端 Handler 中，一般直接使用已经解析的 r.URL。RequestURI 保存客户端发来的原始 request-target，适合需要原始表达时使用，不必每次都重新解析。普通入站请求中的 r.URL 可能只有路径与查询，缺少 scheme 和 host 并不说明请求损坏。

把这个入站字段直接当作出站目的地址，才会混淆两个契约。构造客户端请求时应明确上游地址；客户端请求不能设置非空 RequestURI。本文不展开代理改写，只强调不要通过“补协议并复制原始字段”来掩盖这种差异。

按字段判断，不做自动补全

落地时，先把变量名区分为 pathTarget、reference、endpoint，分别调用对应封装；解析错误通过 %w 保留，不在日志中无条件写出可能含凭据或敏感查询的完整原串。上游业务据输入契约给用户错误提示，而不是一律显示“网址不合法”。

接着检查三个条件：相对引用是否确实需要保留相对语义；路径接口是否允许空值、双斜线或星号；客户端地址是否具备要求的 scheme 与主机。星号请求目标以及 CONNECT 的 authority-form 涉及方法上下文，不属于上面这个普通路径封装的覆盖范围。

这样选择的代价是多一个明确的输入类型，但省去了自动补全带来的歧义。不要为了减少函数数量，把通用 URI 解析、业务字段约束和实际网络可达性混成一个布尔返回值。

相关解析疑问

双斜线开头一定代表主机吗？

不能脱离解析上下文。url.Parse 通常把双斜线起始的引用理解为带 authority 的网络路径引用，而 ParseRequestURI 对无 scheme 的该形式按请求路径处理。因此不要把两个解析器互换后仅比较 String()。

井号为什么不能当作普通 fragment 处理？

ParseRequestURI 假定收到的请求字符串不带 fragment。不要指望它像通用链接解析那样剥离井号后缀。本例提前拒绝原始井号；路径中的字面井号可通过百分号编码表达。

需要先对整串 PathUnescape 吗？

不要先整体反转义再解析。它可能把原本的数据字符变成分隔符。保持原始编码交给对应解析器，使用 Path、RawQuery 和 EscapedPath 等适合当前任务的字段或方法。

通用解析与实现差异可查 https://pkg.go.dev/net/url 和 https://go.dev/src/net/url/url.go；服务端 RequestURI 与 URL 的职责见 https://pkg.go.dev/net/http#Request。