为何在文件监听代码中使用done通道，而非sync包？

1. done通道的实际作用 #

你理解的没错，这段代码里的done通道就是用来阻塞main goroutine，避免程序直接退出。

Go程序的运行规则是：只要main goroutine执行完毕，整个程序就会终止，所有后台goroutine都会被强制结束。而那段监听文件变更的匿名goroutine是个无限循环，会一直运行，但如果main函数不阻塞，会直接走到末尾退出，导致监听逻辑根本没法工作。

这里的done是无缓冲通道，代码里没有任何地方会往它里面发送数据，所以最后的<-done会一直卡在那里，让main函数保持运行状态，直到你用外部信号（比如Ctrl+C）终止程序。

2. 为什么不用sync包实现阻塞？ #

不是不能用sync包，而是用通道更贴合这个场景的需求和Go的并发设计风格：

• 语义更匹配：sync包的WaitGroup是用来等待一组goroutine执行完成的，核心语义是“等待任务结束”。但这段代码里的监听goroutine是无限循环，永远不会“完成”，用WaitGroup的话，你得写wg.Add(1)和wg.Wait()，但goroutine里永远不会调用wg.Done()，虽然也能阻塞，但语义上完全不对，属于“歪用”工具。
• 扩展性更强：如果后续要给程序加优雅退出的逻辑（比如收到终止信号后，先关闭watcher再退出），用通道的方式改起来更方便。比如可以加个信号监听goroutine，收到信号后往done通道里发个值，main函数就能退出，还能执行defer watcher.Close()清理资源。要是用WaitGroup，就得额外加退出控制逻辑，麻烦很多。
• 代码更简洁：用通道只需要两行代码（创建通道+阻塞接收）就能实现需求，比硬套WaitGroup的写法更清爽，也更符合Go开发者的常规写法。

举个反例，硬用WaitGroup的写法会是这样，明显别扭：

var wg sync.WaitGroup
wg.Add(1)
go func() {
    // 这里永远不会执行defer，因为是无限循环
    defer wg.Done()
    // ... 监听逻辑
}()
wg.Wait()

内容的提问来源于stack exchange，提问作者Quentin