fsnotify是实时监听首选，因其基于系统原生事件机制（如Linux inotify），毫秒级响应、资源开销低，而轮询延迟高、CPU不可控且无法感知重命名等事件。
为什么 fsnotify 是实时监听的首选，而不是轮询
因为轮询（比如用 time.Ticker 定期 os.Stat）延迟高、CPU 消耗不可控，且无法感知子目录变化或文件重命名事件。fsnotify 基于操作系统原生 inotify（Linux）、kqueue（macOS）、ReadDirectoryChangesW（Windows），事件触发毫秒级，资源开销极低。
但要注意：fsnotify 不递归监听子目录（默认只监听注册路径本身），也不自动处理符号链接跳转；若需监控整个目录树，必须手动遍历注册每个子目录，或使用封装库如 github.com/fsnotify/fsnotify + 自行递归逻辑。
- 注册监听前确保路径存在且进程有读权限，否则
watch.Add()返回no such file or directory - 监听器需长期运行，
watch.Events是无缓冲 channel，若不及时读取会阻塞内核事件队列，导致后续事件丢失 - 同一路径多次
Add()会报no such file or directory错误，不是“已存在”提示，而是内部状态异常
如何用 filepath.WalkDir 实现安全递归监听
filepath.WalkDir 比旧版 filepath.Walk 更轻量、支持中断，适合在初始化阶段一次性扫描目录结构并为每个子目录调用 watch.Add()。但注意：它不保证原子性——若扫描中途目录被删除或重命名，可能 panic 或漏加监听。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先
os.Stat校验根路径存在且为目录，再开始 Walk - 在
WalkDirFunc中对每个dirEntry判断IsDir()，仅对目录调用watch.Add() - 捕获
filepath.SkipDir错误以跳过权限不足的子目录，避免中断整个扫描 - 监听器启动后，新创建的子目录不会自动被监听，需额外监听父目录的
fsnotify.Create事件并动态Add()
示例片段：
err := filepath.WalkDir(root, func(path string, d fs.DirEntry, err error) error {
if err != nil {
return err
}
if d.IsDir() {
if err := watch.Add(path); err != nil {
log.Printf("skip dir %s: %v", path, err)
return nil // 不中断 walk
}
}
return nil
})
过滤逻辑该放在事件接收协程里，还是单独管道处理
必须放在事件接收协程中。因为 fsnotify 的 Events channel 是共享的，若把过滤逻辑移到下游 goroutine，会导致未过滤事件堆积在 channel 中，最终阻塞监听器——这是最常被忽略的性能陷阱。
正确做法是：在读取 watch.Events 的 goroutine 内部直接判断是否符合转发条件，只将通过过滤的事件发往下游 channel。
- 过滤依据通常包括：
event.Op & fsnotify.Write（忽略Rename或Chmod）、strings.HasSuffix(event.Name, ".log")（扩展名）、!strings.HasPrefix(filepath.Base(event.Name), ".")（排除隐藏文件） - 注意
event.Name是相对路径（相对于监听路径），若需绝对路径，应filepath.Join(watchRoot, event.Name) - 避免在过滤逻辑中做同步 I/O（如读文件内容），会拖慢事件消费速度；如需内容分析，应将文件路径发往 worker pool 异步处理
转发到 Kafka / HTTP / 文件时的可靠性保障要点
转发失败不能丢弃事件，尤其日志类场景要求至少一次语义。但重试机制不能无限制——例如目标服务宕机数小时，盲目重试会撑爆内存。
- 对每条转发任务设置超时（如
http.Client.Timeout = 5 * time.Second），失败后写入本地磁盘暂存（用os.OpenFile(..., os.O_APPEND|os.O_CREATE)），而非内存队列 - 暂存文件需按日期分片（如
forward_fail_20240520.log），避免单文件无限增长 - Kafka 场景下，不要为每次事件新建
sarama.SyncProducer，复用一个 producer 实例，并检查Errors()channel 获取发送失败详情 - HTTP 转发时，若目标返回 4xx/5xx，需根据状态码决定是否重试（如 400 不重试，503 可指数退避）
真正棘手的是：文件被高频覆盖写（如 tail -f 类日志），fsnotify.Write 事件可能密集爆发，而转发链路吞吐跟不上。这时过滤器不仅要判断文件名，还得结合 os.Stat 检查文件修改时间是否更新，避免重复转发同一内容。
