fsnotify无法直接反映读写频率，因其仅触发事件而不统计次数、字节数或时间窗口内频次，连续写入可能合并或拆分，且读操作默认不触发事件。
fsnotify 只能监听事件发生，不能统计读写频率；要监控“频率”，必须自己计数 + 定时采样，否则看到的只是“有没有改”，不是“改得多快”。
为什么 fsnotify 无法直接反映读写频率
fsnotify 是事件驱动模型：一个 Write 事件只表示“至少发生了一次写入”，但连续 100 次写入可能合并成 1 个事件（尤其在 Linux inotify 中），也可能拆成多个（如分块写、flush 触发）。它不暴露字节数、调用次数、耗时，更不提供时间窗口内频次统计。
- 常见错误现象：
event.Op & fsnotify.Write为真，就counter++—— 这会严重低估真实 IO 频率 - 真实场景中，日志轮转、配置热重载、高频小包写入（如 metrics push）都可能导致事件漏报或聚合
- 读操作根本不会触发
fsnotify事件（除非是inotify的IN_ACCESS，但默认不启用且开销大）
如何用 atomic 计数器补全读写指标
真正可控的频率来源，是你自己调用 os.Open、io.Copy、os.WriteFile 等地方。在这些调用点埋点，配合 atomic.AddInt64 才能拿到准确频次。
- ✅ 正确做法：定义包级变量
var fileReadCount int64，在每次os.Open后立即atomic.AddInt64(&fileReadCount, 1) - ✅ 写入频次建议按“调用次数”而非“字节数”统计，因为高频小写（如每秒百次
Write）才是瓶颈根源；若需吞吐量，另用fileWriteBytes单独累加 - ❌ 禁止在 goroutine 栈上声明计数器：
func handle() { var c int64; atomic.AddInt64(&c, 1) }—— 地址逃逸，行为未定义 - ⚠️ 注意：
os.ReadFile和io.ReadAll本质也是os.Open+Read，需统一埋点，否则漏计
如何把原子计数器暴露为 Prometheus 指标
Prometheus 不接受裸 int64，且 Counter 类型语义是“只增”，而你可能需要周期性重置（如每分钟清零算 QPS），所以必须用 Gauge。
立即学习“go语言免费学习笔记（深入）”；
- 定义：
fileReadGauge := prometheus.NewGauge(prometheus.GaugeOpts{Name: "myapp_file_read_total", Help: "Total file read operations"}) - 注册：
prometheus.MustRegister(fileReadGauge) - 同步逻辑（别在
/metricshandler 里实时读！）：go func() { ticker := time.Tick(1 * time.Second) for range ticker { fileReadGauge.Set(float64(atomic.LoadInt64(&fileReadCount))) } }() - 性能提示：同步间隔设为 1–5 秒足够；太短会增加 runtime 调度和锁压力，反而干扰主业务
容易被忽略的埋点位置和语义歧义
读写频率 ≠ 文件变更频率，二者指标来源完全不同，混用会导致监控失真。
- “读频率”应统计所有打开/读取路径：包括
os.Open、os.ReadFile、bufio.NewReader(f).ReadString等，只要底层涉及该文件 fd 的读操作 - “写频率”要区分：是调用
Write的次数（反映 syscall 开销），还是成功写入的字节数（反映吞吐）——两者都要，但不能共用一个变量 - 临时文件、符号链接、/proc 下的伪文件等，可能被频繁打开但不属于业务关注范围，埋点前建议加路径白名单过滤
- 最常被跳过的一步：没做初始化校验 —— 启动时就该用
atomic.StoreInt64(&fileReadCount, 0)显式归零，避免冷启动后读到垃圾值
