fsnotify不能直接监听create事件立即读取csv，因写入可能未flush完成；应结合write事件与文件大小稳定判断，或优先监听rename事件。
为什么 fsnotify 不能直接用于高吞吐文件转换
监听到 .csv 文件创建就立刻用 os.Open 读取，大概率读到空内容或截断数据——因为写入进程可能还没 flush 完。常见现象是转换结果缺失最后几行，或解析报 unexpected EOF。
实操建议：
- 监听
fsnotify.Create后，**不立即处理**，改用fsnotify.Write+ 文件大小稳定判断（连续两次检查间隔 100ms，大小不变） - 对重命名场景（如
log.csv.tmp → log.csv），优先监听fsnotify.Rename，它比Create更可靠 - 避免轮询
os.Stat，改用time.AfterFunc延迟触发校验，减少系统调用开销
如何安全地把 .xlsx 流式转成 .jsonl 而不爆内存
用 tealeg/xlsx 全量加载一个 100MB 的 Excel，Go 进程 RSS 很容易冲到 1.2GB；而真实业务中往往只需提取某几列、跳过前 N 行表头。
实操建议：
- 改用
qax-osu/excelize的f.GetSheetList()+f.GetSheetRow()，按行迭代，每行转map[string]interface{}后直接json.Encoder.Encode()输出 - 设置
runtime.GC()在每处理 5000 行后手动触发，缓解 GC 压力（仅当观察到gc CPU持续 >40% 时启用） - 禁止用
json.Marshal拼接字符串再写入，改用json.NewEncoder(w).Encode(v)避免中间 []byte 分配
io.Pipe 在实时转换链路中的误用陷阱
想把「监听 → 解析 → 转换 → 上传」串成管道，于是写 pr, pw := io.Pipe()，然后在 goroutine 里往 pw 写、主线程从 pr 读——结果经常卡死或 panic: write on closed pipe。
根本原因是 io.Pipe 没有缓冲，且两端任意一端提前关闭就会导致另一端阻塞或 panic。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
实操建议：
- 替换为
chan []byte或bytes.Buffer（小文件）/bufio.Writer（大文件流） - 若必须用管道，务必用
sync.WaitGroup确保写端完成后再 closepw，且读端要 handleio.EOF和io.ErrClosedPipe - 上传环节（如调
http.Post）必须设context.WithTimeout，否则上游卡住会导致整个管道 hang 住
Linux 下 inotify 限制导致监听失效的真实原因
本地测试好好的，部署到服务器后突然不触发事件——大概率是 /proc/sys/fs/inotify/max_user_watches 被耗尽，dmesg | grep inotify 会看到 inotify_add_watch failed: No space left on device。
这不是磁盘空间问题，而是内核 inotify 句柄上限。
实操建议：
- 用
find /path/to/watch -type d | wc -l估算需监听的目录数，确保max_user_watches≥ 目录数 × 2（每个目录至少占 2 个 watch） - 不要递归监听整个
/var/log，改用通配监听/var/log/*.log，再配合fsnotify的NonRecursive模式 - 监听器启动时加校验：
exec.Command("sysctl", "fs.inotify.max_user_watches").Run()，失败则 log.Warn 并提示运维
文件格式转换的“实时”本质是延迟可控，不是毫秒级响应；真正难的是在写入未完成、磁盘 IO 波动、进程意外退出这些常态下保持数据不丢、不重、不错——所有设计都要朝这个目标收束，而不是堆功能。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
