go默认能正确解析utf-8编码的url查询参数，但若前端未声明charset=utf-8或url被gbk编码（如%c4%da%b6%c8），r.url.query().get("name")会返回乱码；真实编码需查rawquery或raw headers，gbk编码须绕过默认解析、手动解码。
Go 默认能正确解析 UTF-8 编码的 URL 查询参数，但一旦前端页面或客户端未声明 charset=UTF-8（比如用 meta http-equiv="Content-Type" content="text/html;charset=GBK"），或者 URL 本身被 GBK 编码过，r.URL.Query().Get("name") 就会返回乱码字节序列，如 "0105 020605"。
确认 URL 查询字符串的真实编码
不能只看浏览器地址栏——它可能已自动解码并重写。真实编码要看原始请求的 Network → Request URL 或 Raw Headers：
- 如果 URL 中中文部分是
%C4%DA%B6%C8这类双字节十六进制，且来源是旧版 IE 或某些国产浏览器表单提交，大概率是 GBK 编码 - 如果是
%E4%B8%AD%E6%96%87这种三字节格式，基本可判定为 UTF-8 -
r.URL.RawQuery返回的是未解码的原始查询字符串，可用于判断编码来源
手动解码 GBK 编码的 URL 查询参数
当确认是 GBK 编码时，不能依赖 r.ParseForm() 或 r.URL.Query()，必须绕过默认解析流程：
- 先调用
r.ParseMultipartForm(32 或 <code>r.ParseForm()前，用io.ReadAll(r.Body)消耗一次 body（注意：body 只能读一次） - 从
r.URL.RawQuery提取查询字符串，用url.PathUnescape解除 URL 编码（得到 GBK 字节流） - 用
golang.org/x/text/encoding/simplifiedchinese.GBK.NewDecoder().Bytes()转为 UTF-8 字节切片 - 再用
url.ParseQuery(string(utf8Bytes))得到正确的url.Values
示例关键片段：
rawQuery := r.URL.RawQuery
unescaped, _ := url.PathUnescape(rawQuery)
gbkBytes := []byte(unescaped)
utf8Bytes, _ := simplifiedchinese.GBK.NewDecoder().Bytes(gbkBytes)
values, _ := url.ParseQuery(string(utf8Bytes))
name := values.Get("name") // 此时 name 是正常中文
避免在 GET 请求中混用编码的源头控制
服务端无法 100% 自动识别编码，最可靠的方式是从源头约束：
- 所有 HTML 表单必须显式声明
<meta charset="UTF-8">，且<form></form>不要设accept-charset - 前端 JS 构造 URL 时，统一用
encodeURIComponent("中文")，它始终按 UTF-8 编码 - 禁止后端主动读取
r.URL.RawQuery后自行拼接或修改——容易破坏原有编码上下文 - 若必须兼容老系统，建议在反向代理层（如 Nginx）统一做 GBK → UTF-8 重写，而非在 Go 应用内处理
真正棘手的不是解码逻辑本身，而是同一个 HTTP 请求里可能同时存在 UTF-8 编码的 Query、GBK 编码的 Form、以及 JSON Body 里的 UTF-8 ——此时靠单一解码策略必败。得按 Content-Type 和来源路径分层处理，且每个分支都要有 fallback 日志记录原始字节。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
