os.removeall易致服务卡顿因其同步递归删除千级小文件或大目录可阻塞主线程数百毫秒至秒级，应改用分批删除+调度让出、大文件先清空再删，并移至独立goroutine执行。
为什么 os.RemoveAll 在日志清理中容易引发服务卡顿
直接用 os.RemoveAll 删除旧日志目录，看似简单，但实际会阻塞主线程 —— 它是同步递归遍历+逐文件 unlink，对千级小文件或大日志目录（如 500MB+ 的 logs/2024-05-12/）可能耗时数百毫秒甚至秒级。而你的 HTTP handler 或定时 goroutine 正在等这个调用返回，请求延迟就上去了。
实操建议：
- 改用
filepath.WalkDir+os.Remove分批删除，每删 50 个文件后runtime.Gosched()让出调度权 - 对单个大文件（>10MB），用
os.Truncate(f, 0)清空再os.Remove，避免内核 page cache 压力突增 - 绝对不要在
http.HandlerFunc或关键路径里调用清理逻辑；应走独立 goroutine + channel 控制并发数（例如最多 2 个清理任务并行）
如何用 fsnotify 实现低开销的实时日志体积告警
轮询 os.Stat 每 5 秒查一次日志目录大小，既浪费 CPU 又不准 —— 新写入的日志可能刚落盘就被跳过。而 fsnotify 能监听 WRITE 和 CREATE 事件，只在真正有变更时触发检查。
实操建议：
- 监听日志目录本身（不是子文件），关注
fsnotify.Write和fsnotify.Create事件，忽略Chmod和Remove - 收到事件后，不立即统计全量大小，而是用
atomic.AddInt64(&logSize, delta)维护一个近似值：写入时按Write返回字节数累加，Create时预估初始大小（如 1MB） - 当
logSize > 2GB，才触发一次精确的filepath.WalkDir校准，并发投递告警到本地 channel（避免阻塞 fsnotify 回调）
log/slog + 自定义 Handler 如何嵌入自动切分与 TTL 判断
原生 slog.NewTextHandler 不知道“该不该切文件”或“这条日志是否已超 7 天”。必须自己实现 slog.Handler，在 Handle 方法里做决策。
实操建议：
- 在
Handle中解析r.Time，与当前日期比对，若超过 TTL（如 7*24*time.Hour），跳过写入，直接返回nil - 检查当前打开的文件句柄是否已存在且
stat.Size() > 100MB，若是，先file.Close()，再用新时间戳命名创建文件（如app-2024-05-12T14:30:00.log） - 务必用
sync.Once初始化首次写入的文件，避免多 goroutine 竞态创建同名文件 - 别在
Handle里做磁盘 IO（如 stat、open）—— 提前缓存lastCheckTime和currentFileSize，每 100 条日志才真实刷新一次
清理策略中容易被忽略的硬链接与容器挂载点问题
在 Docker/K8s 环境下，日志目录常以 bind mount 方式挂载到宿主机。此时 os.RemoveAll 删除的是容器内路径，但宿主机上的文件可能仍被其他进程引用（比如 tail -f 或日志采集 agent），导致磁盘空间不释放 —— 表象是“明明删了，df -h 却没变化”。
实操建议：
- 清理前先用
lsof +D /path/to/logs（宿主机执行）确认是否有进程持有着已删除文件的 fd（状态为deleted） - 对挂载卷，优先用
find /host/logs -name "*.log" -mtime +7 -delete（宿主机执行），而非容器内 Go 程序操作 - 若必须容器内清理，检查
/proc/mounts是否含shared或slave标志，避免umount --lazy干扰日志 agent - 硬链接日志（如某些 rotate 工具生成）需用
os.Lstat检查sys.Stat_t.Nlink，仅当链接数为 1 时才真正删除
真正的难点不在“怎么删”，而在“删的时候系统还在写、还在读、还在被外部进程盯着”。所有策略都得让出调度、避开竞争、绕过挂载语义 —— 否则性能毛刺和磁盘满故障只会更隐蔽。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
