url.QueryEscape 安全处理 Unicode 字符，先 UTF-8 编码再百分号编码，输出如 %E4%B8%AD；需配合 url.Values 使用，避免手动拼接或重复编码。
直接说结论：url.QueryEscape 只处理 ASCII 特殊字符，对中文、emoji 等 Unicode 字符先 UTF-8 编码再百分号编码，结果是标准的 %E4%B8%AD%E6%96%87 这类格式——它本身是安全的，但必须配合 url.Values 或手动拼接时注意不要重复编码。
为什么 url.QueryEscape 会把中文变成 %E4%B8%AD 这种形式
因为 HTTP 查询参数规范（RFC 3986）要求非 ASCII 字符必须先转成 UTF-8 字节序列，再对每个字节做百分号编码。url.QueryEscape 正是按这个逻辑实现的：它不识别“字符”，只处理字节流。
常见错误现象：
• 手动用 url.QueryEscape 处理已 UTF-8 编码的字符串（比如从 []byte 直接传入），导致二次编码，出现 %25E4%25B8%25AD（% 被编码成 %25）
• 把 url.QueryEscape 和 url.PathEscape 混用，后者不处理 / 和 : 等路径保留字符，但 QueryEscape 会编码它们
实操建议：
• 输入始终是原始字符串（string 类型），不要提前 utf8.EncodeRune 或 []byte 转换
• 中文、日文、emoji 都可以直接传进去，函数内部自动完成 UTF-8 + 百分号两步
• 若需兼容老系统（如只接受 GBK 编码的后端），url.QueryEscape 不适用，得自己用 golang.org/x/text/encoding 转码
立即学习“go语言免费学习笔记（深入）”；
拼接 URL 查询参数时，别手写 ? 和 &
手动拼接容易漏转义、多加空格、错位等号，而且 url.QueryEscape 不负责处理键值对结构。
正确做法是用 url.Values：
• 它内部调用 url.QueryEscape，且自动处理 = 和 & 分隔
• 支持重复 key（如 filter=1&filter=2）
• 生成结果可直接用于 http.Get 或 req.URL.RawQuery
示例：
params := url.Values{}
params.Set("q", "Go语言+开发")
params.Add("tag", "后端")
params.Add("tag", "安全") // 重复添加
fullURL := "https://api.example.com/search?" + params.Encode()
// 结果：https://api.example.com/search?q=Go%E8%AF%AD%E8%A8%80%2B%E5%BC%80%E5%8F%91&tag=%E5%90%8E%E7%AB%AF&tag=%E5%AE%89%E5%85%A8
错误写法：
• "?q=" + url.QueryEscape(q) + "&tag=" + url.QueryEscape(tag) —— 容易漏空格、没处理 key 本身含特殊字符（如 user name 作 key）
• url.QueryEscape("q=中&tag=文") —— 整个字符串被当成一个值编码，完全破坏结构
url.QueryEscape 和 net/url 解码函数不是严格互逆
url.QueryEscape 编码后的字符串，用 url.QueryUnescape 可以还原；但反过来，如果原始字符串里本来就有 %20 这类合法编码，url.QueryUnescape 会把它也解掉——这在某些场景下是危险的。
典型问题：
• 后端返回的签名字段含 %（如 HMAC-SHA256 base64 后的 +、/ 被替换为 %2B、%2F），前端误用 url.QueryUnescape 导致签名损坏
• 用户输入中本就包含 %3A（即 :），被双重解码成非法字符
实操建议：
• 只对明确由 url.QueryEscape 生成的值调用 url.QueryUnescape
• 接收外部数据时，优先用 url.ParseQuery（它内部已做一次解码）
• 若需保留原始编码（如透传签名），跳过解码，直接用 RawQuery 或 FormValue（它已自动解码一次）
最常被忽略的一点：url.QueryEscape 不处理空格 → 它转成 %20，而不是 +。虽然大多数服务端能兼容两者，但严格遵循 RFC 的服务器（如某些 Go http.ServeMux 规则）只认 %20。别指望它帮你转成加号形式。
