c.Param()不自动解码路径参数，含中文等UTF-8字符时需手动调用url.PathUnescape()，且必须在路由匹配后立即解码并校验，避免乱码、404或路径遍历风险。
路径未解码导致 Param() 返回乱码或空值
直接用 c.Param("key") 读取含中文、Emoji 或其他 UTF-8 多字节字符的路径参数时，如果前端未做 encodeURIComponent，或反向代理（如 Nginx）提前解码/重写路径，Gin 可能拿到已损坏的原始字节流——c.Param() 内部依赖路由树匹配结果，而匹配发生在 URL 解码前，但参数提取逻辑不自动二次解码。
常见现象：访问 /user/张三 → c.Param("name") 返回 "%E5%BC%A0%E4%B8%89"（即原始编码字符串），而非 "张三"；或更糟：路由根本没匹配上，直接 404。
- 确认前端是否对路径参数做了
encodeURIComponent()（必须做） - 检查反向代理配置，禁用
merge_slashes off或类似自动路径规范化行为，避免提前解码破坏 Gin 的路由树匹配 - 若必须兼容未编码路径，改用
c.Request.URL.Path手动截取 +url.PathUnescape()解码，例如：path := c.Request.URL.Path<br>name := strings.TrimPrefix(path, "/user/")<br>decodedName, _ := url.PathUnescape(name)
通配符 *action 在多字节路径下截断或错位
当使用 /api/*action 这类通配路由时，c.Param("action") 返回的是从第一个 / 开始的剩余路径片段，但 Gin 对该字段不做任何 URL 解码。若路径是 /api/文档/导出.pdf，c.Param("action") 得到的是 "%E6%96%87%E6%A1%A3/%E5%AF%BC%E5%87%BA.pdf"，而非预期的 "文档/导出.pdf"。
- 不要依赖
c.Param("action")直接用于文件系统路径拼接或日志记录 - 务必手动调用
url.PathUnescape()，且注意它可能 panic（如遇到非法编码），建议加 recover 或用url.QueryUnescape()替代（后者对路径更宽容） - 若需精确拆分多级路径段（如
/api/v1/用户/列表），优先用strings.Split(strings.TrimPrefix(c.Request.URL.Path, "/api"), "/")，再逐段解码
CleanPath 对含多字节字符路径的副作用
Gin 底层 httprouter 使用的 CleanPath 函数在标准化路径时，会逐字节扫描并处理 ..、. 和重复 /。但它不识别 UTF-8 多字节序列边界——若路径中出现形如 %E4%BD%A0..%E5%A5%BD（即“你..好”的编码），CleanPath 可能错误地将中间的 %E4%BD%A0..%E5 当作上级目录处理，导致路径被意外截断。
- 生产环境应禁止用户构造含
..的原始路径参数，尤其在多语言场景下 - 所有路径参数进入业务逻辑前，先做
url.PathUnescape()，再验证是否包含..或绝对路径前缀（如/etc/passwd） - 避免在路由定义中直接暴露通配路径给不可信输入，例如不用
/static/*filepath服务任意文件，改用白名单映射
查询参数与路径参数混用时的编码不一致风险
同一个请求里，路径参数（/user/张三）和查询参数（?q=你好）的编码状态可能不同：浏览器对路径部分自动编码，但对 query string 编码规则更宽松；某些 SDK 或 Postman 可能只编码 query 而不编码路径。这会导致 c.Param("name") 和 c.Query("q") 解码行为不一致，难以统一处理。
- 强制约定：所有客户端必须对路径参数和 query 参数均执行
encodeURIComponent() - 服务端统一用
url.QueryUnescape()处理所有参数（它比PathUnescape()更健壮，能容忍部分非法编码） - 若发现
c.Param()返回编码串而c.Query()返回明文，说明前端编码不规范，需修复客户端，而非在服务端做条件分支
