遇到 permission denied 应分类响应：os.ispermission(err) 可跳过继续，os.isnotexist(err) 通常忽略，error_invalid_name 需启用长路径支持，其他错误依场景处理；回调中返回 nil 仅停当前层级，filepath.skipdir 跳过子树，避免 os.stat 补救。
遇到 permission denied 不该 panic，也不该静默跳过——它需要分类响应。
filepath.WalkDir 中 permission denied 的典型表现
常见错误现象是遍历突然中断、日志无输出、或只处理了部分路径。比如在 Linux 上访问 /proc 下的进程目录，或 Windows 上读取被占用的 C:WindowsSystem32config，filepath.WalkDir 回调里会传入非 nil err，但这个 error 并不总是“致命”的。
-
os.IsPermission(err)为 true：用户无读权限，但路径本身合法，可选择跳过该条目继续 -
os.IsNotExist(err)为 true：路径已删除或被移动（竞态常见），通常应忽略 -
errors.Is(err, syscall.ERROR_INVALID_NAME)（Windows）：长路径未启用 manifest 支持，需提前处理或提示 - 其他 error（如 I/O timeout、broken pipe）：视场景决定是否记录后继续
如何在 WalkDir 回调中安全处理权限错误
返回 nil 会让 walk 停在当前层级（不是整个遍历），返回 filepath.SkipDir 只跳过该目录，而返回任意其他 error（如 errors.New("xxx")）会立即终止全部遍历——这和你想“跳过问题目录、继续兄弟分支”的目标相悖。
- 对单个文件/目录的权限错误，直接返回
nil即可（注意：这是允许的，且符合文档语义） - 若想跳过整个子树（比如
.git或node_modules），用return filepath.SkipDir - 若需记录但不停止，建议在外层定义
[]error切片，在回调中append而非依赖返回值 - 不要在回调里
recover()——filepath.WalkDir不捕获 panic，会导致 goroutine 崩溃
为什么不能靠 os.Stat 补救 permission denied
有人试图在回调中对报错路径再调一次 os.Stat 来确认是否存在，这是冗余且危险的：
-
os.Stat会再次触发系统调用，性能差，且大概率复现同样的permission denied - 如果路径是符号链接，
os.Stat会跟随目标，而filepath.WalkDir的err是发生在原路径上的，二者上下文不一致 -
fs.DirEntry.Info()同样会触发stat，失去WalkDir的轻量优势；真需要元数据，应只对明确要处理的路径调用，并检查 error
Windows 长路径与权限错误的耦合问题
在 Windows 上，ERROR_INVALID_NAME 常被误判为权限问题，实际是路径超过 260 字符且程序未启用 long path 支持。这种错误无法通过重试或降权绕过。
- 确保应用 manifest 包含
<application xmlns="urn:schemas-microsoft-com:asm.v3"><windowssettings><longpathaware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longpathaware></windowssettings></application> - 代码中可用
strings.HasPrefix(err.Error(), "The system cannot find the file specified")+len(path) > 260做辅助判断，但不可替代 manifest - 不要尝试用
\?前缀手动转换路径——filepath.WalkDir内部不支持，且跨平台逻辑会断裂
真正麻烦的不是权限错误本身，而是把所有 I/O 错误都当成同一类问题去“统一跳过”。不同错误类型对应不同语义：有的该跳过，有的该告警，有的该退出。别让一个 nil 返回值掩盖了本该暴露的配置或部署缺陷。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
