默认 logger.default 无法直接写入独立文件，因 gorm v2 日志器依赖标准库 log.logger（默认输出到 os.stderr），且会校验 flags/prefix；必须实现 logger.interface 接口并用 os.openfile 创建文件句柄，配合 logger.sqlstring 拼接完整 sql 后写入。
为什么默认的 logger.Default 无法直接写入独立文件
GORM v2 的日志器（GormLogger）默认依赖 Go 标准库的 log.Logger，而后者底层用的是 os.Stderr。即使你替换了它的 io.Writer，GORM 还会额外检查 log.Logger 的 Flags 和 Prefix 是否匹配内部预期；若不一致，可能静默降级为无格式输出或丢失 SQL 参数。
更关键的是：GORM 不直接暴露日志写入目标的控制权，它只接受一个实现了 logger.Interface 的实例 —— 所以你不能靠“改配置”实现，必须自己实现一个符合接口的日志器。
如何自定义 logger.Interface 并写入文件
核心是实现 LogMode、Info、Warn、Error 四个方法，并在 Info 中识别 SQL 日志（通过 sql 字段是否存在、是否含 SELECT/INSERT 等关键字，或更稳妥地判断 ctx.Value(logger.ContextKeyCommand) 是否为 "sql"）。
- 用
os.OpenFile创建带os.O_APPEND | os.O_CREATE | os.O_WRONLY标志的文件句柄，避免每次写都重开文件 - 用
log.New包装该句柄，设置log.LstdFlags | log.Lmicroseconds保证时间精度 - 在
Info方法中，仅当ctx.Value(logger.ContextKeyCommand) == "sql"时才写入该log.Logger，其余日志（如连接池信息）可丢弃或路由到其他输出 - 注意：GORM 会在 SQL 日志中把参数占位符（
?或$1）和实际值分开传，你需要调用logger.SQLString拼接（v2.2.5+ 支持），否则日志里只有问号
示例片段：
file, _ := os.OpenFile("gorm-sql.log", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
sqlLogger := log.New(file, "[SQL] ", log.LstdFlags|log.Lmicroseconds)
// 自定义 logger 实现
type sqlFileLogger struct {
logger.Interface
}
func (l sqlFileLogger) Info(ctx context.Context, msg string, data ...interface{}) {
if cmd, ok := ctx.Value(logger.ContextKeyCommand).(string); ok && cmd == "sql" {
// 拼接带参数的完整 SQL（需 GORM >= v2.2.5）
sql := logger.SQLString(data...)
sqlLogger.Printf("%s | %v", sql, time.Since(logger.NowFunc().(time.Time)))
}
}
常见踩坑点：日志重复、丢失、乱码、权限失败
文件日志最常出问题的地方不是逻辑，而是运行时环境细节：
-
os.OpenFile路径写相对路径（如"logs/gorm.log"）时，实际工作目录可能是启动命令所在路径，不是二进制所在目录 —— 建议用filepath.Dir(os.Args[0])拼绝对路径 - 多个 GORM 实例共用同一个日志器实例时，
log.Logger是并发安全的，但文件句柄本身也是，所以无需额外加锁；但若手动调用file.Close()后继续写，会 panic 报write: bad file descriptor - MySQL 驱动返回的 SQL 中含二进制字段（如
VARBINARY）时，logger.SQLString可能输出不可见字符或乱码 —— 可先对data中的[]byte值做fmt.Sprintf("%x", b)处理再拼接 - Linux 下如果程序以非 root 用户运行，而日志路径在
/var/log等受限目录，OpenFile会返回permission denied错误，且 GORM 默认忽略该错误，导致日志静默失效
要不要用第三方日志库（Zap / Logrus）对接 GORM
可以，但没必要绕大弯：Zap 的 zapcore.WriteSyncer 或 Logrus 的 io.Writer 接口都能直接喂给 log.New，所以你依然得走「自定义 logger.Interface」这条路。Zap 的结构化能力在 SQL 日志里基本用不上 —— 因为 GORM 传来的 data... 是扁平 interface{} 切片，不是 map。
真正值得换的情况只有一种：你的服务已统一用 Zap 记录所有日志，并要求 SQL 日志也带 trace_id、service_name 等字段。这时需要在 Info 方法里从 ctx 提取 zap.Logger 实例（比如存在 ctx.Value("zap-logger")），再调用 logger.Info(..., zap.String("event", "sql"), zap.String("sql", fullSQL))。但这增加了上下文传递负担，且 GORM 自身不管理该 ctx 生命周期。
多数项目，用标准库 log + 文件句柄，已经足够稳定、轻量、可控。
