gin 路由能匹配中文路径是因为内部用 raw path 字节匹配，且 c.param() 已自动解码；需直接写 utf-8 中文路由、避免手动二次解码，并用 url.pathescape 安全生成含中文的 url。
Gin 默认不自动解码路径中的中文（如 /用户/张三 会被浏览器编码为 /%E7%94%A8%E6%88%B7/%E5%BC%A0%E4%B8%89），但能正确匹配已注册的含中文路径；真正的问题出在「你写的路由路径是否包含原始中文」以及「c.Param() 返回值是否需要手动解码」——多数情况下无需额外操作，但有例外。
为什么 Gin 路由能匹配中文路径却显示乱码？
浏览器发起请求时，会自动对 URL 中的非 ASCII 字符（包括中文）执行 UTF-8 编码 + 百分号转义（如 用户 → %E7%94%A8%E6%88%B7）。Gin 的路由匹配器在内部使用的是 raw path（即未解码的字节流），所以只要你注册的路由是 GET("/用户/:name")，Go 会把它当作 UTF-8 字节序列去比对，匹配成功没问题。但如果你在代码里写的是 router.GET("/%E7%94%A8%E6%88%B7/:name")，那就完全无法匹配。
- ✅ 正确做法：直接写中文路径，Gin 支持 UTF-8 字面量（需源文件保存为 UTF-8）
- ⚠️ 常见错误：把浏览器编码后的字符串当路径写进
.GET()，结果路由永远 404 - ? 验证方式：打印
c.Request.URL.Path，看到的是已编码的 raw path（如/%E7%94%A8%E6%88%B7/%E5%BC%A0%E4%B8%89），不是解码后的
c.Param() 返回的中文参数要不要手动 url.QueryUnescape？
c.Param("name") 返回的是**已自动解码后的字符串**，也就是你期望的原始中文（如 "张三"），不需要、也不应该再调用 url.QueryUnescape。这是 Gin 在解析 Params 时隐式完成的一步 —— 它从 raw path 中提取对应 segment 后，立即做了 UTF-8 解码。
- ✅ 可直接用于日志、数据库查询、模板渲染等场景
- ❌ 若再套一层
url.QueryUnescape(c.Param("name"))，会导致重复解码，出现乱码（如张%E4%B8%89→张） - ? 补充：如果路径中混用了未编码字符（比如服务端拼接了未编码的中文到 redirect Location），才可能触发双重编码问题，但那是上游构造错误，不是 Gin 的责任
如何安全地在重定向或生成跳转 URL 时嵌入中文路径？
不要手动拼接中文到 URL 字符串里，否则极易因编码缺失导致 400 或 CDN 拒绝。必须用标准库做编码：
- ✅ 使用
url.PathEscape处理路径段（path segment），例如：url.PathEscape("用户")→"%E7%94%A8%E6%88%B7" - ✅ 使用
url.QueryEscape处理查询参数值（query value），例如：url.QueryEscape("上海&北京")→"%E4%B8%8A%E6%B5%B7%26%E5%8C%97%E4%BA%AC" - ❌ 不要用
strings.ReplaceAll或正则硬替换，也不要用utf8.DecodeRune自己实现 - ⚠️ 注意：
url.Parse不会帮你编码，它只解析；url.URL.String()也不会自动编码路径段，必须提前处理
最易被忽略的一点：Gin 的路由树构建和匹配全程基于字节，不关心字符语义。只要源码文件是 UTF-8、终端/IDE 显示正常、HTTP 客户端（浏览器/curl）按规范编码，整个链路就天然支持中文路径 —— 你唯一要盯住的，是「自己有没有无意中破坏编码环节」，比如手动生成 URL 时漏掉 PathEscape，或者误对已解码的 c.Param() 结果再次解码。
