Go net/url.URL 怎样处理可选字段

Go 的 url.URL 使用空字符串表示许多组件的空值，但它并不是业务表单的“可选字段”模型。处理可选项时，先区分两层：URL 已有的值，以及本次修改有没有提交该字段。查询参数用键的存在性区分缺失与空值；修改请求再用显式状态区分保持、设置和删除。

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

目标和边界：把缺省与空值分开

以商品筛选链接为例，用户没有提交 label，通常表示沿用已有筛选；提交空 label，可能表示选择“空标签”；点击删除筛选则要求查询串不再包含这个键。我倾向于先约定这些语义，再选择结构体，避免一个空字符串承担三种职责。这里的链接和代码是说明用示例，不代表实际运行记录。

User == nil 可以表达没有用户信息；Scheme、Host 等字符串字段没有通用的“是否提交”标志。解析相对引用时，Scheme 或 Host 为空也不必然意味着解析错误。是否只允许绝对 HTTPS 地址，属于调用方另外制定的输入规则。

整体安排：解析、修改、重新组装

实现可以分成三个职责：通过 url.Parse 获得组件；通过 url.ParseQuery 获得查询键值并处理错误；应用业务修改后，用 Values.Encode 写回 RawQuery，再调用 String。图中展示的是这些对象的静态关系。

需要拒绝错误查询串时，应使用 ParseQuery 并检查 err。便捷方法 u.Query() 不返回错误，会略去格式有误的键值对。不要把这种容错行为当作业务已经同意忽略错误。

读取阶段：判断键是否存在，再取值

q.Get("label") 返回空字符串，既可能是没有 label，也可能是 label=。需要分辨时使用 q.Has("label")，或用 values, exists := q["label"] 查看键和全部值。Get 只取第一个值；如果接口允许重复键，应明确采用第一个、全部保留还是直接拒绝。

按查询值模型，?label 和 ?label= 都可以成为键存在、值为空的表示。重新 Encode 后不应期待保留二者原始拼写差异。如果业务处理的是签名原文或要求字节不变的链接，应保留原始字符串，而不是任意解码再编码。

修改阶段：用三态补丁表达意图

下面把补丁状态写成 Apply、Delete、Value 三个字段。Apply 为 false 时忽略其他字段；Apply 为 true 且 Delete 为 true 时删除；剩余情况设置 Value，允许空字符串。真实表单的字段是否出现，必须由接收层传给 Apply，不能根据 Value 是否为空猜测。

package main

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

type Change struct {
    Apply bool
    Delete bool
    Value string
}

func patchQuery(raw string, changes map[string]Change) (string, error) {
    u, err := url.Parse(raw)
    if err != nil {
        return "", fmt.Errorf("解析 URL: %w", err)
    }
    // 查询串单独解析，避免悄悄丢弃格式错误的参数。
    q, err := url.ParseQuery(u.RawQuery)
    if err != nil {
        return "", fmt.Errorf("解析查询参数: %w", err)
    }
    for key, change := range changes {
        if !change.Apply {
            continue // 未提交的字段保持原值。
        }
        if change.Delete {
            q.Del(key) // 删除该键的全部值。
        } else {
            q.Set(key, change.Value) // 空字符串也表示明确设置。
        }
    }
    u.RawQuery = q.Encode()
    // 本例约定：查询键全部删除后，不保留空问号。
    u.ForceQuery = false
    return u.String(), nil
}

func main() {
    result, err := patchQuery(
        "https://example.com/items?label=old&page=2&debug=1",
        map[string]Change{
            "label": {Apply: true, Value: ""},
            "page":  {Apply: false},
            "debug": {Apply: true, Delete: true},
        },
    )
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    fmt.Println(result) // 展示组装结果，不发送网络请求。
}

按照代码的组装规则，label 被设置为空值，page 保持原值，debug 被移除。Set 会把同名键的多个值替换成一个；如果要追加多值，另行使用 Add 并定义追加语义。这个函数针对需要规范化查询参数的普通层级 URL，不承诺原始参数顺序或原始转义形式不变。

序列化阶段：单独决定问号、片段和编码提示

RawQuery == "" 不足以判断最终是否有问号。ForceQuery 为 true 时，即使查询串为空，String 仍会保留问号。本例明确清除 ForceQuery，因此删除全部键后不留下空问号。如果你的协议区分无查询和空查询，应把这项策略独立暴露出来，而不是沿用本例默认值。

Fragment 是不含井号的片段文本。清除片段时可同时清空 Fragment 和 RawFragment；RawFragment 是编码提示，不是“片段已提交”的布尔值。URL 没有对应的 ForceFragment 开关，因此不要指望只靠空 Fragment 区分末尾裸井号和完全没有片段；需要精确保留时，应在业务模型里额外保存状态或原始文本。

Path 和 Fragment 保存解码后的文本。普通赋值时不要先对完整值转义一次再塞进去，否则可能重复编码。修改 Path 后可清空旧 RawPath；修改 Fragment 后可清空旧 RawFragment，让序列化依据新值处理。需要读取编码形式时使用 EscapedPath、EscapedFragment，避免把可选编码提示当作业务必填字段。

推荐约定与速查表

这套做法适合筛选链接、普通配置编辑和链接生成器。我的取舍是让业务补丁负责“有没有提交”，让 URL 类型负责组件和转义。对签名链接、代理透传或要求原文不变的协议，应单独设计保真路径。

常见问题

可以给 URL 加 omitempty 来控制 String 吗？

不可以。omitempty 属于特定序列化格式的字段规则，不会改变 url.URL.String 的行为。即使外层 JSON 省略字段，也仍要自己决定 URL 修改语义。

解析成功就能直接发 HTTP 请求吗？

解析成功只意味着得到了 URI 引用结构。应用如果要求 HTTPS、指定主机或禁止用户信息，仍需按自身规则判断这些组件；本文的补丁函数只组装字符串。

为什么修改 q 后 URL 没变化？

q 是解析得到的 Values，修改后需要把 Encode 的结果写回 RawQuery。只改这个容器，不会自动更新原 URL 字段。

官方依据：URL 字段与序列化、ParseQuery、Values。