Go net/url.URL.EscapedPath 怎么保留原始路径：Path 与 RawPath 的取舍

把请求路径记录下来再重放时，最容易踩到一个细节：/files/a%2Fb 解析后，url.URL.Path 看到的是 /files/a/b，原始写法却可能已经无法从 Path 单独还原。Go 的做法是把解码后的路径放进 Path，把可验证的原始编码提示放进 RawPath，需要输出请求路径时交给 EscapedPath 判断。

要保留 URL 中原始的路径编码，不要直接拼接或读取 RawPath；读取结构化路径用 Path，生成请求字符串用 EscapedPath 或 URL.String。

为什么 Path 看不到原始的 %2F

看一个最小例子。URL 解析器会把路径中的百分号编码解码后存入 Path，所以业务代码按路径层级处理时拿到的是可读值；但这也意味着，仅凭 Path 无法判断某个斜杠原本是普通字符还是 %2F。

package main

import (
    "fmt"
    "net/url"
)

func main() {
    u, _ := url.Parse("https://example.com/files/a%2Fb")
    fmt.Println("Path:", u.Path)
    fmt.Println("RawPath:", u.RawPath)
    fmt.Println("EscapedPath:", u.EscapedPath())
}

输出中的 Path 是 /files/a/b，而 RawPath 仍可能是 /files/a%2Fb。这不是两个不同的业务路径对象，而是同一路径的解码视图和编码提示。

EscapedPath 如何判断 RawPath 能不能复用

EscapedPath 不会无条件返回 RawPath。它先确认 RawPath 是合法的路径编码，再把它解码并与 Path 比较；只有两者一致，原始编码才会被保留，否则 Go 会根据 Path 重新生成转义形式。

这个判断很重要：手动给 URL 结构体塞入互相矛盾的 Path 和 RawPath 时，直接读 RawPath 会把不可信的提示当成结果，而 EscapedPath 会回到一致性检查。

u := &url.URL{
    Path:    "/files/a/b",
    RawPath: "/files/a%2Fb",
}
fmt.Println(u.EscapedPath()) // /files/a%2Fb

u.Path = "/files/c/d"
fmt.Println(u.EscapedPath()) // /files/c/d

URL.String 为什么比手拼路径可靠

URL.String 会调用 EscapedPath 来构造最终 URL。对于代理转发、请求日志回放或需要区分编码斜杠的接口，建议先解析并修改结构化字段，再调用 String，不要把 Path、查询串和主机名直接用字符串拼接。

修改路径时的两个边界

只改 Path，不要复用旧 RawPath

如果 URL 已解析过并且随后修改了 Path，旧的 RawPath 可能只是过期提示。最稳妥的做法是清空它，让 EscapedPath 按新 Path 生成；如果必须保留特殊编码，再同时设置一组能解码回新 Path 的值。

不要用 Path 做原始请求签名

签名协议若区分 /a/b 与 /a%2Fb，应明确约定签名输入采用 EscapedPath 还是完整的 RequestURI。直接使用 Path 会把编码差异抹平，导致签名双方使用不同的规范化结果。

相关问题

RawPath 为空是不是解析失败？

不是。它是可选的编码提示；没有需要保留的特殊写法时为空很正常，EscapedPath 会从 Path 计算结果。

应该直接调用 PathEscape 吗？

单独转义一个路径片段时可以考虑 url.PathEscape；已经有 url.URL 对象时，优先让 EscapedPath 处理整体路径状态。

URL.String 会不会丢掉 %2F？

只要 RawPath 是 Path 的有效编码，String 会通过 EscapedPath 保留它；如果两者不一致，则会重新编码。

小结

Path 负责可读、可处理的解码视图，RawPath 负责可选的原始编码提示，EscapedPath 负责把两者放进一致性规则里。代码只要把“读取路径”和“输出路径”分开，%2F 这类边界就不会在日志、路由和签名之间悄悄变形。