URL编码查询参数必须用url.QueryEscape而非url.PathEscape，因其按application/x-www-form-urlencoded规范将空格转为+、中文转%XX；路径编码才用url.PathEscape。
URL编码必须用 url.QueryEscape，不是 url.PathEscape
处理查询参数（如 ?name=张三&city=北京）时，url.QueryEscape 才是正确选择。它会将中文、空格、斜杠等转为 %XX 形式，并把空格换成 +（符合 application/x-www-form-urlencoded 规范）。而 url.PathEscape 是给 URL 路径段用的，空格变成 %20，且不处理 / 的语义——混用会导致后端解析失败或 400 错误。
-
url.QueryEscape("a b/c")→"a+b%2Fc"（适合 query） -
url.PathEscape("a b/c")→"a%20b%2Fc"（适合 path，如/user/a%20b%2Fc） - 若手动拼接 query 字符串（如
"?"+url.QueryEscape(k)+"="+url.QueryEscape(v)），务必对每个键值单独编码，不能整串编码
解码要用 url.QueryUnescape，注意双解码风险
url.QueryUnescape 能还原 + 和 %XX，但只做一层解码。如果输入已被重复编码（例如 %2520 是 %20 的二次编码），一次调用无法完全还原。常见于前端未规范编码、代理层重写 URL 或日志中截断再拼接的场景。
- 安全做法：解码后检查是否仍含
%或+，必要时循环解码（最多两次，防无限循环） -
url.QueryUnescape("%2520")→"%20"（未完全解）；再调一次才得" " - 不要用
url.PathUnescape解 query，它不处理+，遇到a+b会原样返回，导致数据错乱
构造完整 URL 推荐用 url.URL 结构体 + url.Values
手动字符串拼接容易出错（遗漏 ?、&、编码不一致）。应优先组合结构体：先用 url.Values 构建查询参数，再赋给 url.URL{Query: v.Encode()}。
v := url.Values{}; v.Set("q", "go语言"); u := &url.URL{Scheme: "https", Host: "example.com", Path: "/search", RawQuery: v.Encode()}-
v.Encode()内部调用QueryEscape，自动处理所有键值编码与连接逻辑 - 修改已有 URL 时，用
url.Parse解析后改u.Query().Set，再调u.RawQuery = u.Query().Encode()，避免破坏原有结构
特殊字符如 @、:、/ 在不同位置有不同编码规则
URL 各部分语义不同，编码策略也不同：@ 在 userinfo 中需编码，在 path 中可能不需要；: 在 host:port 中不能编码；/ 在 path 中是分隔符，不应被 QueryEscape 处理。硬套一个函数必然翻车。
立即学习“go语言免费学习笔记（深入）”；
- 用户密码含
@或:？必须用url.UserPassword构造url.User，再塞进url.URL.User - 路径含中文？用
url.PathEscape编码每一段（如"/user/" + url.PathEscape(name)），别碰整个路径字符串 - 不确定某字符是否该编码？查 RFC 3986 —— 只有
unreserved字符（A-Z a-z 0-9 - _ . ~）在任何位置都可不编码
实际项目里最常踩的坑，是把 QueryEscape 当万能编码函数用在路径上，或者解码前没意识到请求来源可能已多重编码。URL 处理不是“编一下、解一下”就完事，得盯住上下文位置和协议规范。
