Go URL RawPath 为什么会让请求路径出现重复转义

如果 Go 请求里原本想发送 /files/a%2Fb，最后却变成了 /files/a%252Fb，通常不是 HTTP 服务端偷偷改了路径，而是客户端把“已经编码的文本”再次当成普通路径编码了。net/url 的分工很明确：Path 保存解码后的值，RawPath 只在需要保留特殊编码时作为提示；构造请求前应让两者保持对应。

最稳妥的规则是：普通组件放进 Path，不要提前调用路径转义；需要保留 %2F 这类原始表示时，让 Path 放解码值、RawPath 放编码值，并在发送前查看 EscapedPath()。

重复转义其实是把传输表示当成了路径值

百分号编码有两个层次：路径值是业务数据，%2F 是这份数据在 URL 中的表示。Go 的 URL 结构把它们分开保存，因此不能把一条已经编码好的 URL 路径再塞回 Path。

下面的对照只打印字符串，不访问网络。左侧把编码文本当成了值，右侧把解码值和编码提示配成一对：

package main

import (
    "fmt"
    "net/url"
)

func main() {
    // 错误：Path 应该放解码值，却把 %2F 当成了普通字符。
    wrong := &url.URL{Scheme: "https", Host: "example.com", Path: "/files/a%2Fb"}

    // 正确：Path 与 RawPath 解码后表示同一条路径。
    right := &url.URL{
        Scheme: "https", Host: "example.com",
        Path: "/files/a/b", RawPath: "/files/a%2Fb",
    }

    fmt.Println(wrong.EscapedPath()) // /files/a%252Fb
    fmt.Println(right.EscapedPath()) // /files/a%2Fb
}

这里的 %25 不是服务端把 %2F 改坏了，而是 URL 编码器在保护 Path 中原本的百分号。只要发现路径里出现连续的 %25，先回头检查赋值入口，通常比修改服务端路由更快。

Path、RawPath 和 EscapedPath 各自负责什么

Path 是程序进行路径判断时使用的解码形式；RawPath 是可选的编码提示，用来保留编码斜杠等原始差异。EscapedPath() 会先判断 RawPath 是否有效，并且解码后是否恰好等于 Path；满足条件才采用它，否则根据 Path 重新编码。

直接解析完整 URL 时，标准库会替你维护这组关系。例如原始地址包含编码斜杠，解析后可以同时看到解码的 Path 和保留差异的 RawPath：

package main

import (
    "fmt"
    "net/url"
)

func main() {
    // 解析完整 URL，让 net/url 同时保存值和必要的原始表示。
    u, err := url.Parse("https://example.com/files/a%2Fb")
    if err != nil {
        panic(err)
    }
    fmt.Println("Path:", u.Path)
    fmt.Println("RawPath:", u.RawPath)
    fmt.Println("EscapedPath:", u.EscapedPath())
}

构造客户端 URL 时怎么保持这组关系

如果路径来自用户输入或数据库，先明确它现在是“原始路径值”还是“已编码文本”。原始值直接赋给 Path；若手里只有完整 URL，直接交给 url.Parse。不要先对整条路径调用 url.PathEscape，再把结果放进 Path。

确实需要区分路径段中的编码斜杠时，可以手工构造配对字段：

package main

import (
    "fmt"
    "net/http"
    "net/url"
)

func main() {
    // Path 是路由或业务层看到的值，RawPath 保留传输层的 %2F。
    u := &url.URL{
        Scheme: "https", Host: "api.example.com",
        Path: "/objects/team/item", RawPath: "/objects/team%2Fitem",
    }

    // 先核对最终请求目标，再交给 HTTP 客户端发送。
    req, err := http.NewRequest(http.MethodGet, u.String(), nil)
    if err != nil {
        panic(err)
    }
    fmt.Println(req.URL.EscapedPath())
    fmt.Println(req.URL.RequestURI())
}

对于一般 REST 路径，通常不需要设置 RawPath：Path: "/objects/team/item" 就足够。RawPath 不是“关闭转义”的开关，也不是让服务器接收任意原始字符串的通道；它必须与 Path 语义一致。

发送请求前怎么确认路径没有被转义两次

排查时按三个观察点走一遍：先看 u.EscapedPath()，确认路径编码；再看 u.String()，确认主机、路径和查询串拼接；最后看 req.URL.RequestURI()，确认客户端要写入请求目标的部分。三者出现差异时，问题通常位于 URL 构造阶段，而不是网络传输阶段。

可以把下面这张小清单放进请求封装函数的单元测试中：

• 输入是完整 URL 时，优先 url.Parse，不要先拆出编码路径再重复 Escape。
• 输入是业务路径值时，只填 Path；需要保留特殊编码时，补上能对应它的 RawPath。
• 断言应围绕 EscapedPath() 或 RequestURI()，不要只断言 Path，否则看不出传输表示是否改变。
• 客户端请求不要手动填写 Request.RequestURI；它是服务端请求行的原始目标字段。

相关问题

为什么 RawPath 设置了却没有效果？

先检查 url.PathUnescape(RawPath) 是否等于 Path，以及编码是否有效。两者不一致时，EscapedPath() 会忽略这个提示。

普通中文路径应该手动调用 PathEscape 吗？

如果中文是路径值，直接放进 Path，由 URL.String 或客户端统一编码。手动 Escape 后再放入 Path，就可能把百分号再次编码。

Path 和 RawQuery 的处理方式一样吗？

不一样。查询参数通常用 url.Values 生成 RawQuery；路径则使用 Path 与可选的 RawPath。不要把查询串的编码规则套到整条路径上。