文件路径必须用url.pathescape编码，不能用url.queryescape；因后者保留/不编码，导致路由解析失败，而前者将/转为%2f确保路径段语义正确。
文件路径必须用 url.PathEscape 编码，不能用 url.QueryEscape —— 后者会把 / 留着不碰，导致路由解析失败或 404。
为什么 url.QueryEscape 不能用于文件路径
它专为 query string 的 value 设计，保留 /、:、@ 等字符不编码，因为这些在查询值里是合法的。但文件路径中的 / 是语义分隔符，比如 /api/v1/files/abc.txt，如果中间段含 /（如用户上传的 folder/name.txt），不编码就会被服务端当多级路径处理。
-
url.QueryEscape("folder/name.txt")→"folder/name.txt"（/没变，错） -
url.PathEscape("folder/name.txt")→"folder%2Fname.txt"（/变成%2F，对） - 误用
QueryEscape编码路径段，拼出的 URL 可能被服务端二次解码，变成%252F（即%2F被再 encode 一次），彻底失效
url.PathEscape 的典型使用场景
适用于所有需要把任意字符串塞进 URL 路径段的位置：S3 object key、RESTful 资源 ID、文件系统映射接口、CDN 路径等。
- 构造
/files/张三/报表.xlsx→ 先url.PathEscape("张三")和url.PathEscape("报表.xlsx")，再拼进路径 - 不要对整个路径调用
PathEscape，比如url.PathEscape("/files/张三")会把开头的/也编码成%2F，结果变成%2Ffiles%2F%E5%BC%A0%E4%B8%89，错误 - 每个路径段单独 escape，再用
/连接："/files/" + url.PathEscape(username) + "/" + url.PathEscape(filename)
空格、中文、特殊字符怎么处理
url.PathEscape 会把空格转成 %20（不是 +），中文转成 %E4%B8%AD，?、=、& 全部转义——这是对的，因为这些字符在路径段里没有语法意义，必须字面传输。
-
url.PathEscape("my file.txt")→"my%20file.txt" -
url.PathEscape("name=张三&id=123")→"name%3D%E5%BC%A0%E4%B8%89%26id%3D123"（注意=和&都被转了） - 别指望它自动加前缀
/或处理连续//，它只管单个段；路径结构逻辑由你控制
解码时必须配对用 url.PathUnescape
服务端收到路径段后，要用 url.PathUnescape 解，不能用 url.QueryUnescape —— 后者把 + 当空格，而 PathEscape 从不产生 +，用错会把 %20 错解成 + 再当成字面加号。
-
s, err := url.PathUnescape(rawSegment)必须检查err，残缺的%AB或非法字符直接返回 error - 日志里截断的路径、前端没编码就发来的脏数据，都可能让
PathUnescape失败，别假设输入一定合法 - 如果路径段来自
req.URL.Path，Go 的net/http默认已做一次解码，但仅限标准路径解析；若你手动提取某一段（比如正则匹配出来的），仍需自己PathUnescape
最易忽略的一点：路径段编码和 query 编码是两套独立规则，混用一次就可能让整个请求卡在网关或路由层。写之前先问自己——这个字符串最终会出现在 URL 的哪一部分？路径段，还是 ?key=value 里的 value？答案决定函数选择。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
