应通过自定义io.writer捕获errors.is(err, syscall.enospc)，在write方法中检测磁盘满并触发告警、降级或切换缓冲；lumberjack等库默认静默丢日志，需包装处理；容器环境还需检查inodes。
Go 日志写入时 write: no space left on device 怎么捕获
Go 标准库的 log 或第三方日志库（如 zap、zerolog）本身不会主动识别磁盘满这类底层 I/O 错误——它们只负责调用 Write，错误由底层 os.File 返回。所以你得在日志写入路径上显式检查错误类型。
关键不是“怎么记录日志”，而是“怎么感知并响应写失败”。标准做法是：所有日志输出最终都落到一个可控制的 io.Writer，而这个 Writer 必须能区分 no space left on device 和其他错误。
- 用
errors.Is(err, syscall.ENOSPC)判断是否为磁盘满（注意：需导入syscall或unix，Windows 下对应syscall.ERROR_HANDLE_DISK_FULL） - 不要用
strings.Contains(err.Error(), "no space left")—— 语言 locale 可能变化，且容易误匹配 - 如果用
rotatingfile类库（如lumberjack），它内部会返回原始syscall.ENOSPC，可直接用errors.Is检查
lumberjack.Logger 写满后不报错？其实是静默丢日志
lumberjack 默认行为是：当写入新日志失败（比如磁盘满），它会忽略错误并继续运行，导致日志丢失且无提示。这不是 bug，是设计选择——但它和运维可观测性冲突。
必须手动包装它的 Write 方法或监听其返回值。最稳妥的方式是把 lumberjack.Logger 包进自定义 io.WriteCloser：
立即学习“go语言免费学习笔记（深入）”；
type SafeRotator struct {
*lumberjack.Logger
onDiskFull func()
}
func (s *SafeRotator) Write(p []byte) (n int, err error) {
n, err = s.Logger.Write(p)
if err != nil && errors.Is(err, syscall.ENOSPC) {
if s.onDiskFull != nil {
s.onDiskFull()
}
}
return
}
- 别依赖
lumberjack.MaxSize防止写满——它只控制轮转，不阻止当前文件写爆磁盘 -
lumberjack的Rotate方法在磁盘满时也会失败，但默认不暴露该错误；你需要重写Rotate或提前检查剩余空间 - Linux 下可用
unix.Statfs在写前检查：statfs.Avail*statfs.Bsize是否低于阈值（例如 100MB）
为什么 log.SetOutput 换成带错误处理的 io.Writer 还是没反应
因为 log.Logger 的 Output 方法在写失败时仅打印到 stderr（仅限 log.LstdFlags 启用时），且不 panic、不重试、不回调——它把错误吞了。
- 必须自己调用
logger.Output并检查返回值，不能只设SetOutput就以为万事大吉 - 更可靠的做法是绕过
log标准库，直接用fmt.Fprintf+ 自定义io.Writer，确保每次写都做errors.Is(err, syscall.ENOSPC) - 如果用了
zap，注意zapcore.Lock和zapcore.LockWriteSyncer不改变底层错误传播逻辑，仍需在WriteEntry中检查
磁盘满时该立刻停服务还是降级？
停服务太激进，降级又容易掩盖问题。真实线上应该分两级响应：
- 首次检测到
syscall.ENOSPC：触发告警、记录紧急事件、切换日志输出到内存缓冲（如bytes.Buffer，上限 1MB），并开始每 5 秒检查一次磁盘空间 - 持续 3 次检查仍满：关闭非核心日志（如
Debug级）、拒绝新日志写入请求、向监控系统发严重事件（不要只打日志） - 切记：任何“自动清理日志”的逻辑（比如删旧文件）必须加锁+校验+限速，否则可能引发竞态或误删
最常被忽略的一点：容器环境里，/var/log 或挂载卷的 inodes 耗尽（df -i）也会导致 ENOSPC，但 statfs 查的是 block 剩余，得额外用 unix.Statfs 或执行 df -i 命令补检查。
