使用方法很简单：
1，先用fsnotify 创建一个监听器；
2，然后放到一个单独的goroutine 监听事件即可，通过channel的方式传递；
package main
import (
"log"
"github.com/fsnotify/fsnotify"
)
func main() {
// 创建文件/目录监听器
watcher, err := fsnotify.NewWatcher()
if err != nil {
log.Fatal(err)
}
defer watcher.Close()
done := make(chan bool)
go func() {
for {
select {
case event, ok := <-watcher.Events:
if !ok {
return
}
// 打印监听事件
log.Println("event:", event)
case _, ok := <-watcher.Errors:
if !ok {
return
}
}
}
}()
// 监听当前目录
err = watcher.Add("./")
if err != nil {
log.Fatal(err)
}
<-done
}
我们测试一下（有惊喜哦）。先把上述程序编译，然后跑起来：
root@ubuntu:~/code/gopher/src/notify# ./notify
再打开一个终端，准备进行你的操作：
先 touch 一个新文件 hello.txt
touch hello.txt
使用 vim 打开这个文件，写入一行数据，然后关闭退出：
vim hello.txt
root@ubuntu:~/code/gopher/src/notify# ./notify # 触发事件：创建的时候 2021/08/20 17:02:52 event: "./hello.txt": CREATE 2021/08/20 17:02:52 event: "./hello.txt": CHMOD # 触发事件：vim 打开初始化的时候（创建 swp 文件） 2021/08/20 17:17:08 event: "./.hello.txt.swp": CREATE 2021/08/20 17:17:08 event: "./.hello.txt.swx": REMOVE 2021/08/20 17:17:08 event: "./.hello.txt.swp": REMOVE 2021/08/20 17:17:08 event: "./.hello.txt.swp": CREATE 2021/08/20 17:17:08 event: "./.hello.txt.swp": WRITE 2021/08/20 17:17:08 event: "./.hello.txt.swp": CHMOD # 触发事件：:w 写入保存的时候 2021/08/20 17:17:53 event: "./4913": REMOVE 2021/08/20 17:17:53 event: "./hello.txt": RENAME 2021/08/20 17:17:53 event: "./hello.txt~": CREATE 2021/08/20 17:17:53 event: "./hello.txt": CREATE 2021/08/20 17:17:53 event: "./hello.txt": WRITE 2021/08/20 17:17:53 event: "./hello.txt": CHMOD 2021/08/20 17:17:53 event: "./hello.txt": CHMOD 2021/08/20 17:17:53 event: "./hello.txt~": REMOVE # 触发事件：:q 的退出时候 2021/08/20 17:17:57 event: "./.hello.txt.swp": WRITE 2021/08/20 17:18:11 event: "./.hello.txt.swp": REMOVE
- 看到了 ~ 镜像文件，还看到了 swp 文件，竟然还看到了 一个 4913 的文件（这个文件也是个临时文件，感兴趣的可以了解一下）；
太神奇了，这样你就有一个新的手段监控你的文件发生的任何事情了。这是什么原理呢？
深层原理
fsnotify 本质上就是对系统能力的一个浅层封装，主要封装了操作系统提供的两个机制：
1，inotify 机制
2，epoll 机制
旁白：真的是何处多有epoll呀，如果还有对epoll不明白的赶紧复习下linux fd系列。
环境声明：
1，inotify机制
什么是inotify机制?
这是一个内核用于通知用户空间程序文件系统变化的机制。
划重点：其实inotify机制的诞生源于一个通用的需求，由于IO/硬件管理都在内核，但用户是有获悉内核时间的强烈需求，比如磁盘的热插拔，文件的增删改。这里就诞生了三个异曲同工的机制：hoplug 机制，udev管理机制，inotify机制。
inotify 的三个接口
操作系统提供了三个接口来支撑，非常简洁：
// fs/notify/inotify/inotify_user.c // 创建 notify fd inotify_init1 // 添加监控路径 inotify_add_watch // 删除一个监控 inotify_rm_watch
用法非常简单，分别对应 inotify fd 的创建，监控的添加和删除。
inotify 怎么实现监控的？
inotify 支持监听的事件非常多，除了增删改，还有访问，移动，打开，关闭，设备卸载等等事件。
内核要上报这些文件 api 事件必然要采集这些事件。在哪一个内核层次采集的呢？
统调用 -> vfs -> 具体文件系统（ ext4 ）-> 块层 -> scsi 层
**答案是：vfs 层。**其实这个很容易理解，这是必然的，因为这是所有“文件”操作的入口。
以 vfs 的 read/write 为例，我们看一下：
ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos) { // ... ret = __vfs_read(file, buf, count, pos); if (ret > 0) { // 事件采集点：访问事件 fsnotify_access(file); } } ssize_t vfs_write(struct file *file, const char __user *buf, size_t count, loff_t *pos) { // ... ret = __vfs_write(file, buf, count, pos); if (ret > 0) { // 事件采集点：修改事件 fsnotify_modify(file); } }
fsnotify_access 和 fsnotify_modify 就是 inotify 机制的一员。有一系列 fsnotify_xxx 的函数，定义在 include/linux/fsnotify.h ，这函数里面全都调用到 fsnotify 这个函数。、
static inline void fsnotify_modify(struct file *file) { // 获取到 inode if (!(file->f_mode & FMODE_NONOTIFY)) { fsnotify_parent(path, NULL, mask); // 采集事件，通知到指定结构 fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0); } }
来看一下 fsnotify 的函数实现，我们简单的梳一下调用栈：
fsnotify -> send_to_group -> inotify_handle_event -> fsnotify_add_event -> wake_up （唤醒等待队列，也就是 epoll）
再看一眼具体的实现（其实非常简单，就是一个事件通知）：
// 把事件通知到相应的 group 上； int fsnotify(struct inode *to_tell, __u32 mask, const void *data, int data_is, const unsigned char *file_name, u32 cookie) { // ... // 把事件通知给正在监听的 fsnotify_group while (fsnotify_iter_select_report_types(&iter_info)) { ret = send_to_group(to_tell, mask, data, data_is, cookie, file_name, &iter_info); if (ret && (mask & ALL_FSNOTIFY_PERM_EVENTS)) goto out; fsnotify_iter_next(&iter_info); } out: return ret; } static int send_to_group(struct inode *to_tell, __u32 mask, const void *data, int data_is, u32 cookie, const unsigned char *file_name, struct fsnotify_iter_info *iter_info) { // 通知相应的 group ，有事来了！ return group->ops->handle_event(group, to_tell, mask, data, data_is, file_name, cookie, iter_info); } // group->ops->handle_event 被赋值为 inotify_handle_event int inotify_handle_event(struct fsnotify_group *group, struct inode *inode, u32 mask, const void *data, int data_type, const unsigned char *file_name, u32 cookie, struct fsnotify_iter_info *iter_info) { // 唤醒事件，通知相应的 group ret = fsnotify_add_event(group, fsn_event, inotify_merge); } // 添加事件到 group int fsnotify_add_event(struct fsnotify_group *group, struct fsnotify_event *event, int (*merge)(struct list_head *, struct fsnotify_event *)) { // 唤醒这个等待队列 wake_up(&group->notification_waitq); }
这里面的逻辑非常简单：把这次的事件通知给关注的 fsnotify_group 结构体，换句话说，就是把事件通知给 inotify fd。
这个就有意思了，inotify fd 句柄创建的时候，file->private_data 上就绑定了一个 fsnotify_group ，这就对上了。这样的话，针对文件的所有操作，都能有一份事件发送到 fsnotify_group 上，inotify fd 就有可读事件了。
inotify 也有支持 epoll 机制
在前面我们也提到了，Go 的 fsnotify 主要使用了两个系统机制 inotify 机制和 epoll 机制。fsnotify 把 inotify fd 放到 epoll 池里面管理。
换句话说，inotify fd 支持 epoll 机制。划重点：有最明显的两个特征：
- inotify fd 的
inotify_fops实现了.poll接口； - inotify fd 相关的某个结构体一定有个 wait 队列的表头；
这个结构体是啥？
其实跟 timerfd 类似（读者有不熟悉的，可以去复习下哦），笔者直接揭秘啦，这个结构体就是 fsnotify_group 。被存放在 inotify fd 对应的 file->private_data 字段。这个 wait 队列表头就是 group->notification_waitq 。
来看一眼结构体的简要关系：
2 epoll 机制
回到 Go 的 fsnotify 库的实现原理，fsnotify 利用的第二个系统机制就是 epoll 。inotify fd 通过 inotify_init1 创建出来之后，会把 inotify fd 注册进 epoll 管理，监听 inotify fd 的可读事件。
inotify fd 的可读事件能是啥？
就是它监听的文件或者路径发生的增删改的事件嘛，这些事件就是内核 inotify 报上来的。
报上来之后，epoll 监控到 inotify fd 可读，用户通过 read 调用，把 inotify fd 里面的“数据”读出来。这个读出来的所谓的“数据”就是一个个文件事件。
我们看一眼整体的模块层次：
总结
- Go 的 fsnotify 库很方便对文件、目录做监控，这里的充满了想象力，因为一切皆文件，这代表着一切可监控。童鞋们，这里的想象空间非常大哦；
- 通过 fsnotify 我们映证了 vim 的秘密；
- Go 的 fsnotify 其实操作系统能力的浅层封装，Linux 本质就是对 inotify 机制；
- inotify 也是一个特殊句柄，属于匿名句柄之一，这个句柄用于文件的事件监控；
- fsnotify 用 epoll 机制对 inotify fd 的可读事件进行监控，实现 IO 多路复用的事件通知机制；
后记
“总有刁民想害朕”，终于不怕文件被偷偷动手脚了，有了 fsnotify 之后，文件（目录）做的任何事情我总能第一时间感知到。
今天又学到一个新的 fd 类型呢，inotify fd，一个用于监控文件事件的机制，这个在一切皆文件的 Linux 中，尤为重要，因为这代表着一切可监控！！！这里面能做到的事情太多了。