Go解析URL核心是url.Parse()得*url.URL，但易在特殊字符、空值判断、路径编码上出错：协议缺失、未编码中文/空格/#、不可见字符是“invalid URL”三大主因；Values.Get()无法区分key不存在与值为空，须用len(values["k"])>0判断；Path为解码后字符串，RawPath为编码后，构造URL应赋解码值，显示或逻辑处理优先用Path。
Go 里解析 URL，核心就一条：用 url.Parse() 得到 *url.URL，再按需取字段；但直接这么用，90% 的人会在特殊字符、空值判断、路径编码上栽跟头。
url.Parse() 报 “invalid URL” 怎么快速定位？
错误信息只说 “invalid URL”，不告诉你哪错了。常见真实原因有三个：
- 协议头缺失，比如传入
"example.com/path"而不是"https://example.com/path" - URL 字符串含未编码的中文、空格、
#、?等（例如"https://a.com/你好"会失败） - 复制粘贴带了不可见字符（BOM、换行、零宽空格），
strings.TrimSpace()预处理能解决一半问题
更稳妥的做法是：对用户输入或第三方返回的 URL，优先用 url.ParseRequestURI() —— 它强制要求 scheme，能早一步暴露协议缺失问题。
query 参数取值：为什么 Values.Get("k") 总是空？
url.Values 是 map[string][]string，Get() 只返回第一个值，且对“key 不存在”和“key 存在但值为空”都返回空字符串，完全无法区分。
立即学习“go语言免费学习笔记（深入）”；
-
?a=&b=1→values["a"]是[]string{""}，不是nil -
?b=1→values["a"]是nil（长度为 0） - 要判断 key 是否存在，必须用
len(values["k"]) > 0，而不是values.Get("k") != "" -
url.ParseQuery()不解码 value，%E4%BD%A0还是字面量，需要手动调url.QueryUnescape()
Path 和 RawPath 到底该用哪个？
u.Path 是已解码后的 Unicode 字符串（如 /你好），u.EscapedPath() 或 u.RawPath 是编码后的（如 /%E4%BD%A0%E5%A5%BD）。选错会导致 double-encode 或解码失败。
- 构造新 URL 时，赋给
Path的内容必须是已解码的字符串；Go 内部会自动编码 - 读取已有 URL 的路径用于显示或逻辑处理，优先用
u.Path - 做签名比对、透传原始路径、或与第三方系统严格对齐时，才用
u.EscapedPath() - 误把
u.RawPath当作u.Path赋值给新 URL，浏览器会打不开
ResolveReference() 补全相对路径前必须确认 base 合法
u.ResolveReference(ref) 用于把 ./api 这类相对路径补全成绝对 URL，但它**完全不校验 u 是否是合法的绝对 URL**。
- 如果
u是url.URL{Host: "example.com"}（缺Scheme），ResolveReference仍会返回结果，但极大概率是错的 - 调用前必须确保
u.Scheme != "" && u.Host != ""，否则先用url.ParseRequestURI()校验 - 常见场景是处理重定向 Location 头或 HTML 中的
<a href="./xxx">，base 来自上游响应，不能盲目信任
真正麻烦的从来不是解析本身，而是你不知道自己没意识到哪些字符被悄悄转义了、哪些 key 其实根本没传、哪些路径你以为是原始的其实已经被 decode 过一遍 —— 这些细节在日志里不报错，在测试里不暴露，上线后才开始掉链子。
