不能直接拼接字符串构造 query，因为会跳过 url 编码，导致空格、中文、&、= 等字符破坏参数结构，引发解析截断、误拆或 400 错误；必须使用 url.values.encode() 或 url.queryescape。
Go 标准库的 url.Values 已经提供了安全、符合规范的 URL 参数序列化与反序列化能力，不需要额外引入第三方包——但直接用 url.ParseQuery 或 url.Values.Encode 时，容易忽略编码一致性、空值处理和特殊字符边界。
为什么不能直接拼接字符串构造 query？
手动拼接 "key=value&key2=value2" 会跳过 URL 编码，导致空格、中文、&、= 等字符破坏参数结构。浏览器或服务端解析时可能截断、误拆或报错。标准做法必须调用 url.QueryEscape 或依赖 url.Values 内置编码逻辑。
-
url.Values的Encode()方法自动对 key 和 value 分别调用url.QueryEscape - 手动拼接 +
url.QueryEscape可行，但易漏掉 key 的编码（例如url.QueryEscape("user name") + "=" + url.QueryEscape("张三")） - 若参数来自用户输入或外部 API，未编码的 value 可能触发 400 错误或被服务端静默截断
如何正确序列化 map[string]string 到 query string？
使用 url.Values 作为中间结构，而非直传 map。它内部按 RFC 3986 规范编码，并支持重复 key（如 filter=1&filter=2）。
- 初始化：
v := url.Values{}，然后用v.Set("k", "v")或v.Add("k", "v")（Add允许重复，Set覆盖） - 从已有 map 构建：遍历 map，对每个 key/value 调用
v.Set(url.QueryEscape(k), url.QueryEscape(v))—— 但注意：url.Values内部已编码，**不要重复调用QueryEscape**；直接v.Set(k, v)即可 - 生成 query string：
v.Encode()，结果如"name=%E5%BC%A0%E4%B8%89&city=%E5%8C%97%E4%BA%AC" - 若需附加到 URL，用
u.RawQuery = v.Encode()（u是*url.URL），避免二次编码
如何从 query string 安全反序列化为 map？
用 url.ParseQuery，不是 strings.Split 或正则——它能正确处理编码字符、重复 key、空值和边界情况（如 a=&b=1 中的空字符串 a=""）。
-
m, err := url.ParseQuery("q=go+lang&lang=zh&tag=")返回map[string][]string，注意 value 是切片（因允许重复 key） - 单值场景常用：
if vals, ok := m["lang"]; ok && len(vals) > 0 { lang := vals[0] } - 空参数
tag=会被解析为[]string{""}，不是 nil；若业务需区分“未传”和“传了空串”，得结合原始 query 字符串判断 - 不推荐用
url.Parse后取.RawQuery再解析：它会把 fragment（#...）前的内容全当 query，且不校验格式
常见坑：中文、+ 号、数组参数与 GET/POST 混用
url.Values 对空格编码为 +（符合 application/x-www-form-urlencoded 规范），但某些 API（尤其 RESTful JSON 接口）期望空格为 %20。此时需手动替换或改用 net/url 底层函数。
- GET 请求中，query string 必须用
url.Values.Encode()；POST 表单同理，但若 POST JSON，则不应走此流程 - 数组参数如
ids[]=1&ids[]=2不是标准，url.ParseQuery会解析为map[string][]string{"ids[]": {"1","2"}}，需业务层清洗 key 名（如去掉[]） - 若 query 来自前端
URLSearchParams.toString()，其空格也编码为+，与 GoEncode()一致，可直接互操作 - 调试时用
fmt.Printf("%q", v.Encode())查看实际发送的字符串，比日志裸打更可靠
最易被忽略的是：query string 的编码规范和业务语义不总是一致的——比如有些老系统把 + 当字面量而非空格，这时候就得在序列化后全局替换 + 为 %20，或改用 url.PathEscape 配合手动拼接。别假设所有服务都严格遵循 RFC。
