Go fsnotify 怎样同时消费文件事件与错误通道

我第一次把 fsnotify 接进配置热加载器时，文件修改事件能够正常打印，真正的监听错误却常常没有进入业务日志。问题不在于要为 Events 和 Errors 各开一个 goroutine，而在于必须持续同时消费两个通道，并把“通道已关闭”和“收到错误”分开处理。

官方地址：https://github.com/fsnotify/fsnotify

先把“事件正常、错误丢失”的症状拆开

fsnotify 的 Watcher 同时暴露 Events 和 Errors。前者承载路径与操作类型，后者承载监听器错误；如果循环只读 Events，错误通道没有消费者，排查时就只会看到“某个文件改了”，看不到监听队列溢出、底层资源不足等线索。

我会先把问题限定在三个边界：NewWatcher 或 Add 失败属于启动阶段；运行期间的底层监听异常来自 Errors；正常停止则由通道关闭或外部退出信号触发。这样日志不会把“监听结束”误报成“监听出错”。

用一个 select 同时消费两个通道

最小的可维护写法，是让读取循环同时覆盖事件、错误和外部停止信号。下面的示例把 context.Context 作为退出边界；代码块中的日志只表示示例输出位置，不把任何一次未执行的结果当成运行证据。

package main

import (
    "context"
    "errors"
    "fmt"
    "log"

    "github.com/fsnotify/fsnotify"
)

func consume(ctx context.Context, watcher *fsnotify.Watcher) error {
    for {
        select {
        case event, ok := 

这里有两个容易被忽略的细节。第一，event, ok := 与错误通道都要判断 ok；第二，错误是否应该终止循环取决于业务策略，像 ErrEventOverflow 这类错误至少应该升级给上层，而不是打印后继续假装监听可靠。

启动、运行和关闭要分成三段

监听器生命周期最好按“创建与 Add、消费、关闭”拆开。NewWatcher 或 Add 失败时没有可靠的事件循环可跑；进入消费阶段后才同时处理两个通道；退出时再调用一次 Close 释放底层资源。不要把 Add 放到消费循环里反复尝试，否则会让真正的错误和重试策略混在一起。

func watch(ctx context.Context, path string) error {
    watcher, err := fsnotify.NewWatcher()
    if err != nil {
        // 创建失败发生在启动阶段，直接返回给调用方。
        return fmt.Errorf("创建 watcher: %w", err)
    }
    defer func() {
        // 无论消费循环如何退出，都只在这里统一释放资源。
        if closeErr := watcher.Close(); closeErr != nil {
            log.Printf("关闭 watcher 失败：%v", closeErr)
        }
    }()

    if err := watcher.Add(path); err != nil {
        // Add 失败不是 Events 通道里的事件，保持启动错误的语义。
        return fmt.Errorf("添加监听路径 %q: %w", path, err)
    }

    return consume(ctx, watcher)
}

调用方可以根据返回值决定重试、退出或触发告警。关闭时不要再从同一个 watcher 派生新的监听任务；同时也不要把文件路径的过滤误写成递归监听，fsnotify 的公共 API 仍要求为想观察的目录分别添加 watch。

遇到错误时先判断它属于哪一层

我实际排查时会按下面的顺序缩小范围：

另外，Write 不等于“文件已经写完”，一次用户写入可能产生多个写事件；编辑器采用临时文件替换时，监听单个文件还可能丢失原有 watch。要做配置热加载，通常应该监听父目录，再用 Event.Name 过滤目标文件，并在业务层做短暂去重或重新读取。

常见问题

Events 和 Errors 必须由两个 goroutine 分别读取吗？

不必须。官方示例就是在同一个 goroutine 中用 select 同时读取两个通道；只有当业务处理本身很慢、需要独立调度时，才另行设计工作队列。

可以直接判断 event.Op == fsnotify.Write 吗？

不建议。操作值是位掩码，同一个事件可能携带多个操作，使用 event.Has 更符合 API 语义。

Errors 通道关闭后还能继续监听吗？

应把通道关闭视为当前 watcher 生命周期结束的信号，并让消费函数退出；如果业务需要恢复，应由上层重新创建 watcher、重新 Add 路径，并记录这次恢复原因。