url.QueryEscape不兼容RFC3986，因其按application/x-www-form-urlencoded规范将空格编码为+、~编码为%7E；正确做法是用url.PathEscape预处理后还原/和?，再对每个查询值单独转义。
为什么 url.QueryEscape 和 url.QueryUnescape 不能直接用于 RFC3986 兼容场景
Go 标准库的 url.QueryEscape 默认使用 + 替代空格，且对 ~ 进行转义（变成 %7E），这与 RFC3986 明确要求的“~ 是子分隔符，不应被转义”冲突。实际对接 OAuth2、JWT、OpenAPI 或某些严格校验签名的 HTTP 服务时，这种偏差会导致签名失败或 400 错误。
-
url.QueryEscape("a b~c")→"a+b%7Ec"（错误：空格应为%20，~不该转义） - RFC3986 正确结果应为
"a%20b~c" - 根本原因是
url.QueryEscape实际遵循的是 HTML 表单编码规范（application/x-www-form-urlencoded），而非 RFC3986
用 url.PathEscape + 手动替换实现 RFC3986 查询字符串转义
url.PathEscape 更接近 RFC3986，它保留 ~、.、-、_，但会把空格转成 %20 —— 这正是查询字符串需要的。只需额外处理 / 和 ?（它们在路径中需转义，但在查询字符串中是合法字面量）。
- 安全字符集（RFC3986 §2.2）：字母、数字、
-._~无需转义 - 查询字符串中，
/?=&是分隔符，应保持原样，不参与转义 - 正确做法：先用
url.PathEscape处理整个字符串，再把%2F（/）和%3F（?）还原回来
func QueryEscapeRFC3986(s string) string {
escaped := url.PathEscape(s)
escaped = strings.ReplaceAll(escaped, "%2F", "/")
escaped = strings.ReplaceAll(escaped, "%3F", "?")
return escaped
}
url.PathUnescape 可直接用于 RFC3986 反转义，但要注意错误处理
url.PathUnescape 严格按 RFC3986 解码，支持 %20、接受 ~ 等未转义字符，且不把 + 当空格 —— 这和 url.QueryUnescape 的行为完全不同。它就是你要的反转义函数。
-
url.PathUnescape("a%20b~c")→"a b~c"✅ -
url.PathUnescape("a+b~c")→"a+b~c"（不会误把+当空格）✅ - 必须检查返回的
error：非法十六进制（如%xz）、不完整转义（如%2）都会返回非 nil error - 不要忽略 error，尤其在解析外部输入（如 query 参数）时，应拒绝非法编码
实际使用时最容易漏掉的两个细节
一是键值对边界处理：RFC3986 转义只作用于 value（或 key）本身，不是整个 key=value&... 字符串；二是多值场景下，每个 value 都要单独转义，不能对拼接后的完整 query string 整体调用一次 QueryEscapeRFC3986。
立即学习“go语言免费学习笔记（深入）”；
- 错误示范：
QueryEscapeRFC3986("k=v1&k=v2")→ 会把&和=错误转义 - 正确做法：对每个
v1、v2单独转义，再拼接："k=" + QueryEscapeRFC3986(v1) + "&k=" + QueryEscapeRFC3986(v2) - 如果用
url.Values构造 query，它的Encode()方法仍用旧逻辑，必须手动遍历并替换 value
真正麻烦的地方不在转义函数本身，而在你得时刻记住：标准库里没有“开箱即用”的 RFC3986 查询字符串工具，所有涉及第三方 API 签名或严格协议交互的场景，都得自己兜底处理边界。
