备份前必须调用db.Ping()验证连接可用性，避免因连接池断开或超时导致备份失败；建议封装带健康检查的GetDBForBackup()函数，并在失败时返回503及具体错误信息。
备份数据前必须确认数据库连接是否可用
很多备份失败其实卡在第一步：Gin 启动时没报错，但执行 BackupDB 时连不上数据库。别依赖全局 db 变量的初始化日志——它可能只是“连过一次”，后续连接池已断开或超时。
- 每次备份前用
db.Ping()主动探测，失败则返回503 Service Unavailable并附带错误详情（比如"failed to ping database: timeout"） - 避免在
gin.Context中复用未校验的db实例；建议封装一个带健康检查的GetDBForBackup()函数 - PostgreSQL 用户注意：
pgx驱动下Ping()不触发真正的网络请求，需改用Exec("SELECT 1")或启用pgxpool.Config.HealthCheckPeriod
导出 CSV 时字段顺序和 NULL 处理不能靠 ORM 自动推断
Gin 路由里调用 sql.Rows.Scan 读取结果后，直接写入 csv.Writer 很容易丢字段、错顺序、把 NULL 写成空字符串甚至 panic。
- 显式定义列名数组，例如：
[]string{"id", "name", "created_at", "status"}，和rows.Columns()对齐，不依赖struct字段顺序 - 对每列使用
sql.NullString等类型接收，再判断.Valid写入"NULL"或实际值，避免interface{}直接转字符串出现<nil></nil> - 导出大表时加
rows.SetFetchSize(1000)（PostgreSQL）或分页查询，否则内存暴涨，Gin 默认 32MB 请求体限制会直接 413
生成备份文件要绕过 Gin 的响应生命周期管理
用 c.Header("Content-Disposition", "attachment; filename=backup.sql") + c.Data(...) 导出 SQL 文件看似简单，但实际会触发 Gin 的中间件链（如 logger、recovery），还可能被 gzip 压缩破坏二进制内容。
- 手动设置
c.Writer.WriteHeader(200)，然后用c.Writer.Write()直接写入字节流，跳过所有 Gin 响应包装逻辑 - SQL 备份优先用
pg_dump或mysqldump命令行生成，Go 只做进程启动和流转发；不要用SELECT ... INTO OUTFILE—— 权限受限且无法跨库 - 文件名务必用
time.Now().Format("20060102150405")时间戳，别用uuid，方便运维按时间归档
并发备份请求必须加分布式锁，单机锁毫无意义
本地 sync.Mutex 在多实例部署下完全失效，两个 Pod 同时执行 pg_dump 会导致备份文件损坏或数据库锁表超时。
立即学习“go语言免费学习笔记（深入）”；
- 用 Redis 的
SET backup:lock EX 300 NX实现租约锁，失败立即返回423 Locked和剩余租期 - 锁释放必须用 Lua 脚本原子执行：
if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end，防止误删其他实例的锁 - 备份完成后主动清理临时文件（如
/tmp/backup_*.sql），别指望系统自动回收——容器重启后 /tmp 可能清空，但残留文件会占满磁盘
