直接调用mysqldump/pg_dump可行但非安全备份默认解法，需显式处理Stdout/Stderr、避免Output()导致OOM、密码禁用命令行传递、pg_dump需加--no-owner，MySQL纯SQL备份适用于中小库。
Go 里用 exec.Command 调用 mysqldump 或 pg_dump 是可行的，但不是“安全备份”的默认解法
直接调用外部 dump 命令在开发或轻量场景下能快速落地，但它绕过了 Go 的错误传播机制、权限控制和资源生命周期管理。一旦 dump 过程卡住、超时、输出乱码或被信号中断，cmd.Run() 可能挂起或静默失败——而你根本收不到明确的 exit code 或 stderr 内容。
- 必须显式设置
cmd.Stdout和cmd.Stderr，否则输出丢失，debug 时只能靠日志猜 - 不要用
cmd.Output()拿大体积 dump 数据，容易 OOM；改用io.Copy流式写入文件 - 密码不能拼在命令行里（
-psecret），会被ps aux看见；应通过配置文件（如~/.my.cnf）或环境变量传入 - PostgreSQL 的
pg_dump默认不带--no-owner，恢复时可能因用户不存在报错ERROR: role "xxx" does not exist
MySQL 备份：用 mysqldump 生成 SQL 文件，关键在参数组合
纯 SQL 备份适合小到中型库（
- 必备参数：
--single-transaction --routines --triggers --events --set-gtid-purged=OFF（避免 GTID 冲突） - 排除干扰：
--skip-comments --skip-opt减少注释和冗余语句，降低解析失败风险 - 导出前先检查连接：
mysql -h $host -u $user -e "SELECT 1"，别等 dump 到一半才报Access denied - 示例片段：
cmd := exec.Command("mysqldump", "-h", host, "-u", user, "--single-transaction", "--routines", "--triggers", "--events", "--set-gtid-purged=OFF", dbname) cmd.Env = append(os.Environ(), "MYSQL_PWD="+password) // 避免明文密码
PostgreSQL 恢复：用 pg_restore 加 -c -C 清理再建库最稳
如果备份是 pg_dump -Fc（自定义格式），就不能用 psql 导入。直接 pg_restore 并指定目标库名，否则它会试图还原到 dump 里的原库名——而那个库很可能不存在。
- 恢复前确保目标库已存在：
createdb -h $host -U $user targetdb，否则pg_restore -d targetdb会报database "xxx" does not exist - 加
-c（clean）+-C（create）才能自动删旧库、重建库结构；不加就只往现有库里塞数据，容易主键冲突 - 权限问题常见于
pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of database xxx—— 此时需用 superuser 执行，或提前ALTER DATABASE xxx OWNER TO $user - 不要忽略
--if-exists：它能让-c更安全，避免 “drop db not exists” 报错中断流程
超时与信号处理：不设 cmd.WaitDelay 就等于没做容错
dump 一个 10GB 的库可能耗时数分钟，Go 默认不会等那么久。更麻烦的是，如果用户 Ctrl+C，子进程还在后台跑，变成僵尸进程。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
context.WithTimeout包裹cmd.Start()+cmd.Wait()，否则Run()会无限阻塞 - 恢复阶段更要设超时：比如
pg_restore在网络抖动时可能卡在 COPY 阶段，不超时就永远 hang 住 - 用
os.Interrupt捕获 Ctrl+C，并主动调用cmd.Process.Kill()，否则子进程残留 - 注意：
cmd.Wait()返回的 error 不一定是业务错误——要检查err != nil后再用cmd.ProcessState.ExitCode()判断是否真失败
