url.Parse按RFC 3986解析URL，返回*url.URL结构体，关键字段包括Scheme、Host（含端口）、User、Path、RawQuery（不含?）、Fragment、Opaque；Host不等于域名，需用Hostname()提取；还原完整URL应调用u.String()而非手动拼接。
url.Parse 会把 URL 拆成哪些字段
url.Parse 返回一个 *url.URL 结构体，它不是字符串切分，而是按 RFC 3986 语义解析。真正有用的字段是：Host（含端口）、Path、RawQuery（未解码的查询串）、Fragment，还有 Scheme 和 Opaque（用于非标准 URL）。注意：Host 不等于域名——https://user:pass@example.com:8080/path 的 Host 是 example.com:8080，用户信息和密码在 User 字段里。
常见错误现象：u, _ := url.Parse("http://a.b/c?d=e#f"); fmt.Println(u.Host, u.Path, u.RawQuery) 输出 a.b /c d=e —— 看似正常，但如果你直接拼 u.Host + u.Path 构造新 URL，就丢了 Scheme，也漏了可能存在的端口或用户信息。
- 要还原完整地址用
u.String()，别手动拼 -
Path开头带/，但不保证以单斜杠结尾；RawQuery不含?，Fragment不含# - 如果 URL 含中文或特殊字符（如空格、
+），RawQuery保持原样，Query()方法才做解码
Query() 和 RawQuery 的区别与误用场景
u.RawQuery 是原始字节串，比如 "q=%E4%BD%A0%E5%A5%BD&lang=zh"；而 u.Query() 返回 url.Values（本质是 map[string][]string），自动解码并支持重复键。但这个解码是“尽力而为”：无效 UTF-8 会变成 \ufffd，且不校验编码是否匹配 Content-Type。
典型误用：u.Query().Get("q") 在处理 q=hello+world 时返回 "hello world"（+ 被当空格），但若后端实际用的是 application/x-www-form-urlencoded 以外的编码（比如 JSON 查询参数），Query() 就会错解。
立即学习“go语言免费学习笔记（深入）”；
- 只在确认 URL 查询参数符合标准表单编码时用
Query() - 需要保留原始编码或做自定义解析（如解析 base64 编码的参数），直接读
RawQuery并手动url.ParseQuery或正则拆分 -
url.ParseQuery对RawQuery解析更可控，但它仍按&和=切分，不处理嵌套或非标准分隔符
Host 和 Hostname() 的坑：端口、IPv6、空 Host
u.Host 包含端口（如 "[::1]:8080"），u.Hostname() 才剥离端口。但 IPv6 地址带方括号，Hostname() 会去掉 [ 和 ]，而 Host 不会。如果 URL 是 file:///path/to/file，Host 是空字符串，Hostname() 也返回空——此时不能假设它一定有值。
错误示例：if u.Host == "example.com" { ... } 在遇到 example.com:443 或 [2001:db8::1] 时都失败；又或者用 net.ParseIP(u.Host) 处理带端口的字符串直接 panic。
- 判断域名用
u.Hostname()，再比对；端口单独取u.Port() - IPv6 地址必须用
net.ParseIP(u.Hostname())，不能传u.Host - 对
file://、data://等无 Host 的协议，u.Host为空，别硬解
Parse 和 ParseRequestURI 的关键差异
url.Parse 支持完整 URL（含 Scheme），而 url.ParseRequestURI 专为 HTTP 请求行中的路径设计，它把输入当作相对 URI 处理：不检查 Scheme，允许无协议，且会把开头的 // 当作网络路径（类似 https:// 后的双斜杠）。比如 url.ParseRequestURI("//a.b/c") 返回 Host="a.b", Path="/c"；但 url.Parse("//a.b/c") 会报错 parse "//a.b/c": first path segment in URL cannot contain colon。
常见混淆点：HTTP 代理或反向代理日志里出现的 GET http://x.y/z HTTP/1.1 这种绝对请求 URI，必须用 url.Parse；而 Nginx $request_uri 或 Go http.Request.RequestURI 字段（如 /path?a=b）才适合 ParseRequestURI。
- 收到 HTTP 请求时，用
r.URL（已解析好），别再 parser.RequestURI - 解析用户输入的完整 URL（比如配置项、命令行参数），一律用
url.Parse -
ParseRequestURI不处理查询参数编码，行为和Parse一致，只是入口约束不同
url.Parse 在遇到非法字符时可能静默截断或返回部分结果，而不是报错——所以生产环境务必检查 err，别只用 _ 忽略。 
