Go url.ResolveReference 遇到查询参数和片段时怎么保留目标部分

Go 的 url.ResolveReference 按 URL 引用规则选择路径、查询串和片段，不会自动合并两组查询参数。要保留目标部分，先明确引用是否提供了新路径、是否显式带有问号，再决定是否需要额外的业务继承。只有片段的引用通常保留基础查询串；带新路径的引用通常不会继承基础查询串。

官方地址：https://pkg.go.dev/net/url

批量处理链接时，先拆清 URL 的字段边界

页面索引、文档导航或批量导入服务经常把一份基础地址与大量相对引用组合。请求量增加后，把问号和井号当作普通字符串拼接的做法容易把旧参数带到新页面。这里讨论的是解析设计，未引用任何线上吞吐数据。

统一用基础地址 https://docs.example/guide/chapter?lang=zh#intro 说明。这个地址中的 Path 是页面路径，RawQuery 保存不含问号的原始查询文本，Fragment 表示片段；ForceQuery 用于区分“没有查询部分”和“存在问号但查询为空”。Fragment 与 RawFragment 分别涉及片段内容及可选的转义表示。

ResolveReference 接收已解析的 URL 对象，并返回一个新的 URL 实例。它不是查询参数字典的合并器，也不是直接修改接收者的方法。将基础地址与引用分别解析，能够避免一处字符串截断改变另一字段的意义。

原有拼接方式为什么容易丢失或多带参数

最常见的误解是“引用没有写某字段，就总沿用基础值”。实际需要连同路径一起判断。对于这里的普通分层 URL，引用路径为空、ForceQuery 为 false 且 RawQuery 为空时，Go 才进入基础查询串继承分支。在该分支中，如果引用的 Fragment 也为空，还会继承基础片段。

因此，#details 只改变片段并保留旧查询；?page=2 改用新查询，旧查询不会拼入，新查询分支也不会保留基础片段。next 指向另一个相对路径，其查询和片段来自引用自身。所谓“丢失”很多时候是业务期待继承与标准引用规则不同。

显式的空查询 ? 也不能按空字符串处理：它的 RawQuery 虽然为空，但 ForceQuery 为 true，结果会保留末尾问号，而不会恢复 lang 参数。相反，单独的 # 在 Go 的 URL 字段表示中没有独立的“显式空片段”标记；对本例解析后可能重新继承 intro。若业务目的确实是清除片段，应在解析完成后明确清空 Fragment 和 RawFragment。

把解析集中在一个小函数里

下面的函数只做解析与引用求解，不重新编码查询串，也不偷偷追加参数。基础地址限定为带方案和主机的普通分层 URL，输入错误交给调用者处理。示例没有发起网络请求。

package main

import (
    "fmt"
    "net/url"
)

// resolveLink 只应用引用解析，不混入业务参数继承。
func resolveLink(baseText, refText string) (*url.URL, error) {
    base, err := url.Parse(baseText)
    if err != nil {
        return nil, fmt.Errorf("解析基础地址: %w", err)
    }
    // 本例只支持具有主机的普通分层地址。
    if base.Scheme == "" || base.Host == "" || base.Opaque != "" {
        return nil, fmt.Errorf("基础地址必须包含方案和主机")
    }
    ref, err := url.Parse(refText)
    if err != nil {
        return nil, fmt.Errorf("解析相对引用: %w", err)
    }
    return base.ResolveReference(ref), nil
}

func main() {
    base := "https://docs.example/guide/chapter?lang=zh#intro"
    for _, ref := range []string{"", "#details", "?page=2", "?", "next"} {
        target, err := resolveLink(base, ref)
        if err != nil {
            // 单条失败不应被静默转换成基础地址。
            fmt.Println("解析失败:", err)
            continue
        }
        fmt.Printf("%q 对应 %s\n", ref, target.String())
    }
}

下表按官方解析语义推导，作为阅读示例的对照，不是本机执行记录。为了便于比较，省略相同的方案与主机。

业务需要保留字段时，把补全作为独立策略

如果站点要求跳转到新路径仍带某个语言参数，这是一项业务规则，应在标准求解后单独实现。不能通过“只要 RawQuery 为空就复制基础查询”的通用补丁处理，否则会把用户显式指定的空查询覆盖掉，也会把只适用于旧页面的筛选参数带到新页面。

本题要求不改写参数内容，因此示例没有调用 Query 后再 Encode。后一种写法会重新序列化参数，可能改变顺序及转义形式；它适合按键操作的业务，却不适合要求保持原始查询表示的场景。若确实需要字典式合并，必须另行定义同名键、多值和覆盖优先级。

对于“保留查询，但清空定位片段”这一明确要求，可以只修改新返回的 URL，避免改动共享基础对象：

// target 是 ResolveReference 返回的新 URL，不修改共享 base。
target := base.ResolveReference(ref)
// 显式清除片段及它的原始转义提示，查询字段保持原样。
target.Fragment = ""
target.RawFragment = ""
link := target.String()
_ = link

这个片段假定 base 和 ref 已完成解析。不要让多个 goroutine 一边读取基础对象、一边修改它的字段；批量服务可以把解析后的基础对象视为只读输入，每条记录持有自己的目标对象。这里不承诺性能提升，收益是让字段归属更容易解释。

接入后观察什么，后续还应约束什么

接入阶段可按“只有片段、只有查询、显式空查询、新路径”分类记录解析失败数及业务拒绝数。日志应避免记录可能含敏感值的完整查询串，保留引用类别与失败原因通常更合适。没有真实运行数据时，不应把这些设计指标写成已经取得的上线结果。

另一个必要的边界是基础路径的末尾斜杠：chapter 会被当作最后一个路径段，而 chapter/ 表示目录形式，二者对 next 的解析位置不同。此处没有修改路径内容来强行保持某种目录效果，应由基础地址来源保证意图正确。若允许绝对引用，它会覆盖基础地址；引用求解本身也不等同于允许该目标进入后续请求。

相关问题

ResolveReference 会把 page=2 加到 lang=zh 后面吗？不会。引用显式提供查询时使用它的查询，字典式合并需要单独定义。

为什么空字符串与问号的结果不一样？问号代表显式存在查询部分，即使内容为空，ForceQuery 仍参与判断。

只设置 Fragment 为空为什么还要处理 RawFragment？两者共同描述片段及其可选转义表示，业务清除时一起处理更明确。

合并后能得到独立 URL 吗？该方法返回新 URL 实例；代码仍应把共享基础对象当作只读输入。

参考：Go net/url 方法文档、Go URL 引用解析实现。