QueryEscape和QueryUnescape专用于URL查询参数的编码与解码，按RFC 3986仅转义对query value不安全的字符（如空格→%20、中文→%E4%B8%AD），不转义/、:等路径敏感符；QueryUnescape用于解码，但net/http已自动处理请求中的query，通常无需手动调用。
Go 里 QueryEscape 和 QueryUnescape 是干啥的
它们专用于 URL 查询参数（即 ?key=value 中的 value）的编码与解码，不是通用字符串转义工具。比如空格变 %20、中文变 %E4%B8%AD，但斜杠 /、冒号 : 这类在路径中敏感的字符，在查询值里默认不转义——因为 QueryEscape 只处理“对 query value 不安全”的字符，按 RFC 3986 定义。
常见错误现象：QueryEscape("a/b") 返回 "a/b"（没变），但你可能误以为它该变成 "a%2Fb"；这其实正确，因为 / 在 query value 里是合法的；真要转义斜杠，得用 PathEscape。
-
QueryEscape适用于url.Values.Encode()底层，也适合拼接?k1=v1&k2=v2的 value 部分 - 别用它处理完整 URL 或路径段（如
/api/v1/users/123），那会漏转义 - 它不处理 Unicode normalization，如果输入含组合字符（如带重音的字母），输出可能和浏览器行为不一致
什么时候该用 PathEscape 而不是 QueryEscape
路径段（path segment）里的特殊字符必须严格转义，比如用户 ID 是 user/name，放进 /users/user/name 就得确保斜杠被编码，否则路由解析直接出错。这时 QueryEscape 失效，必须换 url.PathEscape。
典型场景：构造 RESTful 路径、S3 key 名、文件系统路径映射到 HTTP 路由。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
PathEscape("a/b")→"a%2Fb"，PathEscape("hello world")→"hello%20world" -
PathEscape对?、=、&也会转义，而QueryEscape不会（因为这些在 query string 里有语法意义） - 注意：
PathEscape不加/前缀或后缀，也不处理连续斜杠逻辑，它只管单个段
QueryUnescape 解码失败的常见原因
最常遇到的是 url.QueryUnescape: invalid URL encoded string 错误，根本原因是输入不是合法的 percent-encoded 字符串，比如残缺的 %AB（少一位）、非十六进制字符 %XZ、或者未编码的控制字符混入。
真实使用场景：从 HTTP 请求中读取 req.URL.Query().Get("q") 后再解码——但其实没必要，因为 net/http 已自动对 query 做了 QueryUnescape，直接取值就是解码后的字符串。
- 只有当你手动拼接或从非标准来源（如日志、第三方 API body）拿到百分号编码串时，才需要显式调用
QueryUnescape - 若不确定输入是否干净，用
QueryUnescape+errors.Is(err, url.InvalidHostError)判断不妥——它返回的是*url.Error，应检查err != nil并按需 fallback - 注意：
QueryUnescape允许大小写混合的 hex（%ab和%AB都行），但不接受空格或换行
中文、emoji 和保留字符的实际表现
Go 的 QueryEscape 对 UTF-8 字符按字节编码，所以中文、emoji 都能正确转成 %xx 序列；但像 + 这种字符，它不会变成 %2B（因为 + 在 query 中常被用作空格别名，但 QueryEscape 按 RFC 严格处理，空格才变 %20，+ 本身不变）。
这意味着：如果你的前端用 encodeURIComponent 编码，后端用 QueryEscape，两者行为基本对齐；但若前端用老式 encodeURI 或手动替换 +，就可能不一致。
-
QueryEscape("你好?")→"%E4%BD%A0%E5%A5%BD%F0%9F%98%8A"（正确） -
QueryEscape("a+b")→"a+b"（+未被转义，符合规范） - 想强制转义
+？只能自己预处理：strings.ReplaceAll(s, "+", "%2B")，但通常没必要
真正容易被忽略的是：URL 编码只解决传输安全，不解决语义歧义。比如 key=foo%3Dbar 解码后是 foo=bar，但如果你本意是让等号作为值的一部分而非分隔符，就得靠协议约定或额外字段标识——编码本身不携带结构信息。
