filepath.Walk更安全因其内置路径规范化、循环检测和错误聚合，可恢复syscall.EACCES等错误并支持SkipDir跳过子树，而手动递归易因符号链接或权限问题panic。
为什么 filepath.Walk 比递归自己写更安全
直接用 for 循环加 os.ReadDir 递归遍历目录，容易在符号链接、权限不足或深度嵌套时 panic 或无限循环。filepath.Walk 内部做了路径规范化、循环检测和错误聚合，返回的 error 是可恢复的（比如跳过无权限目录），而不是直接崩溃。
- 遇到
syscall.EACCES时，filepath.Walk会调用你传入的WalkFunc，你可以返回filepath.SkipDir跳过子树 - 它自动处理
..和符号链接，避免路径越界（前提是没开filepath.Walk的WalkDir变体） - 注意：它不保证遍历顺序，也不支持并发控制——如果需要并发，得用
fs.WalkDir+ 自定义调度
fsnotify 监听文件变化时为何总漏事件
常见现象是新建文件、重命名或快速连续写入时收不到 fsnotify.Event，根本原因是操作系统底层 inotify/kqueue 的缓冲区溢出或事件合并策略。不是代码写错了，而是默认配置太保守。
- Linux 下必须调大
/proc/sys/fs/inotify/max_user_watches（常需设为 524288），否则新增监听直接失败并静默丢弃 -
fsnotify.Watcher.Add只监听单层目录；要监听子目录，得手动递归Add，或用社区库如github.com/fsnotify/fsnotify的WatchTree - 写入完成前触发
Write事件很常见——真正可靠的判断依据是Chmod或Remove后再出现Create，或配合os.Stat校验ModTime是否稳定
用 os.DirEntry 替代 os.FileInfo 的实际收益
Go 1.16+ 引入 os.DirEntry，它不强制读取 inode 元数据，比 os.ReadDir 返回的 os.FileInfo 快得多。但很多人不知道何时该用哪个。
- 如果只判断是目录还是文件（
IsDir()）、获取名字（Name()），用os.DirEntry；需要大小、修改时间等才调Info() -
filepath.Walk回调里的os.FileInfo已经是完整元数据，不用额外Stat；但fs.WalkDir的fs.DirEntry默认不带这些，得显式调Info() - 注意：
os.DirEntry.Type()在 Windows 上可能返回0，跨平台判断类型优先用IsDir()而非位运算
目录遍历 + 实时监听如何避免重复处理同一文件
启动时先遍历全量目录，再开启监听，两者交集处最容易重复触发逻辑（比如“加载配置文件”被跑两次）。没有银弹，但有可落地的隔离方案。
立即学习“go语言免费学习笔记（深入）”；
- 给每个文件维护一个内存
map[string]time.Time，记录上次处理时间；监听到事件时，对比ModTime是否更新，否则忽略 - 遍历时对每个文件计算
os.Stat().ModTime().UnixNano()作为指纹存入 map；监听回调里先查 map，存在且时间一致就跳过 - 不要依赖文件名唯一性——重命名后又新建同名文件，时间戳可能相同，稳妥做法是加
os.Stat().Size()或用os.ReadFile前几个字节做轻量哈希
真正的难点不在代码怎么写，而在边界：符号链接指向循环目录、NFS 挂载点延迟、容器内 /proc 目录的伪文件……这些地方 filepath.Walk 会报错，fsnotify 可能完全失灵，得单独加白名单或跳过策略。
