需同时启用系统注册表LongPathsEnabled=1并为Go程序嵌入含longPathAware=true的manifest，os.Open等标准库函数才会自动处理超长路径，无需手动加?前缀。
Windows 上 os.Open 报 ERROR_PATH_NOT_FOUND 怎么办
这不是 Go 代码写错了，是 Windows 系统在底层拦截了超长路径。默认 MAX_PATH=260，哪怕路径真实存在、Go 版本 ≥1.16，os.Open 仍会直接返回 ERROR_PATH_NOT_FOUND。
必须同时满足两个条件才有效：
- 系统注册表开启长路径支持：修改
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystemLongPathsEnabled值为1 - Go 可执行文件嵌入 manifest 声明支持：新建
app.manifest，内容含true - 构建时用
go build -ldflags "-manifest app.manifest"（去掉-H windowsgui若需控制台输出）
验证是否生效：用 Sysinternals 的 sigcheck -m yourapp.exe 查看输出中是否有 longPathAware = true。
Go 代码里要不要手动加 ? 前缀
绝大多数情况——不要加。
os.Open、os.Stat、os.ReadDir 等标准库函数内部已自动处理：只要 manifest 和系统开关都就位，它们会悄悄把路径转成 ? 格式调用 Win32 API。
手动加反而容易出错，因为 ? 路径有硬性限制：
- 必须是绝对路径（不能以
.或..开头） - 不经过当前目录解析，
filepath.Join("sub", "..", "file.txt")这类结果无法直接用 - 传给
os.Open会触发invalid argument错误
唯一需要你手动加的场景：调用 syscall.CreateFile 或其他裸 Win32 API 时，且你已确保路径绝对、已 filepath.Abs、已 filepath.ToSlash 或按需转义。
跨平台路径拼接为什么不能用字符串 +
硬编码 "dir\sub\file.txt" 或 "dir/sub/file.txt" 在另一平台会失效，甚至被部分 Windows API 拒绝（比如某些 COM 接口只认反斜杠）。
正确做法永远是用 filepath.Join：
-
filepath.Join("logs", "2024", "error.log")→ Windows 输出logs4error.log，Linux 输出logs/2024/error.log - 它不只是换分隔符：还会自动清理冗余
/、处理空段、适配os.PathSeparator - 和
os.MkdirAll、os.Open等函数天然兼容，避免因格式不匹配导致os.IsNotExist误判
URL 或日志打印等非文件系统上下文，才用 path.Join 或 filepath.ToSlash 统一为正斜杠。
filepath.Clean 在 HTTP Server 中可能吃掉大量 CPU
Go 的 http.ServeMux 内部对每个请求路径都调一次 path.Clean，而该函数对超长 URL（如带几千字符 query 或嵌套路径）做反复扫描和重写，极易成为性能瓶颈。
简单有效的缓解方式：
- 前置长度拦截：
if len(r.URL.Path) > 4096 { http.Error(w, "URI Too Long", http.StatusUriTooLong); return } - 若路由有固定前缀（如所有 API 都是
/api/开头），用http.StripPrefix提前切掉，后续自己用strings.HasPrefix或switch分发，完全绕过path.Clean - 避免在中间件里反复调
filepath.Clean(r.URL.Path)—— 它是为文件路径设计的，不是为 URL 设计的
真正要处理文件系统路径时，filepath.Clean 才有意义；但它的开销比 path.Clean 更高，因要适配系统分隔符逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
