Go URL 为什么加号被解析成空格

如果地址中的 ?q=C++ 被 Go 读成 C ，首先看读取位置：url.ParseQuery 和 URL.Query 使用查询参数的转义规则，裸加号代表空格；字面加号应在发送端写成 %2B。路径里的加号不是这套含义，不能把“所有 URL 的加号都会变空格”当作结论。

另一类故障发生在接收端：发送方已经正确编码，但业务代码把解析后的参数再次交给 QueryUnescape。修复重点是划清原始查询串与业务值的边界，而不是把所有空格替换回加号。Go 标准库入口：https://pkg.go.dev/net/url。

为什么只有查询参数里的加号变成空格

先确认字符串属于哪个组件。RawQuery 是问号后的编码文本，不带问号；业务参数是对这段文本解析后的结果。查询解析器赋予裸加号空格语义，路径解析则不把它解释为空格。这是规则差异，不是字符集导致的随机丢失。

Go 的 url.go 源码把查询组件和路径组件作为不同模式处理，因此不要拿路径的解码函数替代整个查询解析器，也不要对完整 URL 执行 QueryUnescape。

这张表是规则推导，不是本机执行记录。排障时用不含敏感信息的固定样例对照，才能判断实际入口是否采用相同规则。

怎样区分原始查询串与已经解码的值

建议在接口和变量名上就区分 rawQuery 与 term。前者可能包含百分号转义和参数分隔符，后者是业务实际搜索词。把二者都命名为 url 或 query，很容易让后续代码“再保险”地做一次解码。

例如 q=C%2B%2B 的业务值是 C++，但业务原文若恰好是 C%2B%2B，百分号本身也需要编码，查询表示就会包含 %25。看见 %25 不能直接判定多编码，应先问发送方交付的是原文还是已编码文本。

不要先对整段 RawQuery 解码，再按 & 拆参数。业务值中被编码的分隔符可能因此变成结构字符。应让参数解析器负责组件拆分与值的解码。

发送 C++ 时应该怎样编码

下面的原创例子让 SearchURL 只接收原文，并把编码工作留在 URL 的输出边界。固定域名只用于字符串示例，不代表实际搜索服务，也不需要网络访问。

package main

import (
    "fmt"
    "net/url"
)

// SearchURL 只接收未做百分号编码的业务原文。
func SearchURL(term string) string {
    u := url.URL{Scheme: "https", Host: "example.com", Path: "/search"}
    q := url.Values{}
    q.Set("q", term)
    u.RawQuery = q.Encode()
    return u.String()
}

func main() {
    // 示例只构造和解析字符串，不向示例域名发请求。
    link := SearchURL("C++ 入门")
    u, err := url.Parse(link)
    if err != nil {
        fmt.Println("URL 格式错误:", err)
        return
    }
    // 排障时显式解析查询串，不能忽略非法转义错误。
    q, err := url.ParseQuery(u.RawQuery)
    if err != nil {
        fmt.Println("查询参数格式错误:", err)
        return
    }
    // 参数已经解码，不再调用 QueryUnescape。
    fmt.Printf("编码后的查询串: %s\n", u.RawQuery)
    fmt.Printf("业务参数: %q\n", q.Get("q"))
}

按 API 语义，查询串应为 q=C%2B%2B+%E5%85%A5%E9%97%A8，读回的业务字符串应保持 C++ 入门。这里给的是读者可核对的预期，不声称已运行代码。

如果输入先经过 QueryEscape，再交给 Values.Set，百分号会再次编码；接收方读回的可能仍是转义文本。正确边界是原文进入 Values，Encode 生成 RawQuery，而不是在每个函数之间重复编码。

接收端为什么不能再次 QueryUnescape

q.Get 返回值已经越过查询解析边界。再做 QueryUnescape 会把恢复出来的字面加号当成新的空格标记，形成“发送正确、业务仍出错”的现象。修复时删除多余解码，而不是给发送方增加一层编码来迎合错误。

只有协议明确约定某个参数本身承载另一层编码文本，才按该字段的契约单独处理。普通搜索词、文件标题不应默认存在第二层。对不可信输入盲目重复解码，还会让日志、鉴权和业务看到不同字符串。

同样不要全局把空格换成加号：输入可能真的包含空格，且相同的空格结果已经无法告诉你最初是裸加号还是其他空格表示。丢失语义后应回到发送端修复。

路径中的加号应该用什么规则

对于单个路径段，使用 PathEscape；对于对应的已编码路径段，使用 PathUnescape。后者保留裸加号的含义。若已经取得 URL.Path，它通常已是解码后的路径表示，不应默认再解码一次；需要保留编码形式时再看 EscapedPath 等接口的契约。

PathEscape 的输入是一个路径段，不是包含斜杠层级的整个路径，也不是带参数的完整 URL。不要为保留加号而把查询值改用路径编码器；特殊字符的职责不只涉及加号，接口仍应遵从自己的组件规则。相关区别见 PathUnescape 官方说明。

仍有异常时怎样缩小排查范围

为什么同一个 URL 在日志里看起来没问题？

日志可能显示的是 RawQuery，也可能显示解析后的参数。给无敏感信息的复现样例分别标注“编码文本”和“业务值”，并用 %q 等形式显式展示空格；不要把真实令牌、完整签名地址或个人信息直接写日志。

怎样发现格式错误，而不是拿到空字符串？

排障入口使用 ParseQuery 并处理 error。URL.Query 会舍弃格式不合法的参数对，而 Get 的空值也不足以区分缺失与空参数；需要判断存在性时检查参数映射，重名参数还应明确取一个还是保留全部。参见 URL.Query 文档。

签名接口可以重新 Encode 后再比较吗？

应遵守签名协议指定的规范化规则。业务含义相同不等于原始字节一致，重编码可能改变空格表示或参数顺序。不要用通用 URL 修复代码替代签名协议，也不要为修复加号而重写所有请求地址。

最终只需明确三个问题：当前字符串属于查询还是路径，它是否已经解码，以及哪一侧拥有编码责任。修复发生在准确边界上，加号和真实空格才不会相互冒充。