必须分清url.queryescape（用于query参数值，空格→+）和url.pathescape（用于路径段，空格→%20、/→%2f），混用会导致路由失败或解析错误；多参数应使用url.values.encode()自动编码，解码须检查error并避免重复解码。
url.QueryEscape 和 url.PathEscape 必须分清用途，混用会导致路由匹配失败或参数解析错误。
Go 的 URL 编码不是“一个函数打天下”。你得先判断：这个字符串是要塞进 ?key=value 里，还是放进 /api/user/张三 这种路径段里。选错函数，轻则请求 400，重则被反向代理静默丢弃。
query 参数值该用 url.QueryEscape
它专为 query string 的 value 设计，规则明确：
- 空格 →
+（不是%20），这是application/x-www-form-urlencoded标准行为 -
/、:、?、=、&这些在 query 中有语法意义的字符，默认不编码 —— 除非它们是值的一部分（比如path/to/file作为参数值） - 中文、单引号、括号、加号等一律转义：
url.QueryEscape("a/b c")→"a%2Fb+c" - 别拿它去编码整个 URL：
url.QueryEscape("https://a.com?q=1")会把冒号和斜杠也干掉，结果根本不是合法 URL
路径段必须用 url.PathEscape
路径里的 / 是语义分隔符，不能乱动；但用户输入的 ID 或文件名里如果含 /，又必须编码，否则路由直接崩。这时 url.PathEscape 才是正解：
- 它保留路径结构（不加前缀/后缀），只对单个段做编码：
url.PathEscape("user/name")→"user%2Fname" - 空格 →
%20（不是+），+字符本身也会被编码（+→%2B） - 误用
url.QueryEscape编码路径段，/变成%2F，而 Gin、Echo 等框架默认不解码%2F，导致/api/v1/users/user%2Fname匹配不到/api/v1/users/{id} - 如果你要拼完整路径（如
/files/用户上传/abc.txt），先拆成段，再逐段PathEscape，最后用/拼接
多参数场景别手拼，用 url.URL + url.Values
手动拼 ?a= + QueryEscape(a) + &b= + QueryEscape(b) 容易漏空值、错顺序、多写 &，还绕不开重复 key、布尔值处理等边界问题：
- 先
u, _ := url.Parse("https://api.com/search") - 再
params := url.Values{}，然后params.Set("q", "hello world")、params.Add("tag", "go") - 最后
u.RawQuery = params.Encode()，调用u.String()得到完整 URL -
params.Encode()内部自动对每个 key/value 单独调用QueryEscape，且保证=和&位置正确
解码时永远检查 error，别信“应该没问题”
url.QueryUnescape 和 url.PathUnescape 都返回 (string, error)。生产环境里，用户或中间件可能传畸形编码串（如 %xz、% 结尾、UTF-8 截断），忽略 err 会导致：
- 后续逻辑 panic（比如解码后字符串长度突变）
- 静默返回空字符串，掩盖真实数据
- 双重解码漏洞（例如服务端已自动解码过 query，你还手动调一次
QueryUnescape） - HTTP 请求中，
req.URL.Query().Get("key")已是解码后的值，无需再调QueryUnescape
最常被忽略的一点：路径段编码后，某些 CDN 或网关会自动解码一次，而你的服务又调了一次 PathUnescape，结果变成双解——%252F 变成 %2F 再变成 /，路径语义彻底失控。是否解码、在哪解码，得看整个链路谁负责。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
