用 exec.command 调用 mysqldump 需确保：1. 使用绝对路径（如 /usr/bin/mysqldump）；2. 运行 go 的系统用户需有对应 mysql 账号权限；3. 密码含特殊字符时改用 --defaults-extra-file；4. innodb 备份必加 --single-transaction 和 --skip-lock-tables；5. 恢复优先用 shell 重定向而非 stdinpipe。
用 exec.Command 调用 mysqldump 时权限和路径经常出错
Go 本身不内置数据库导出逻辑，必须依赖系统 mysqldump。但直接写 exec.Command("mysqldump", ...) 很容易失败，不是因为代码写错，而是环境没对齐。
-
mysqldump不在$PATH里？用绝对路径，比如/usr/bin/mysqldump或先which mysqldump查准位置 - MySQL 用户没给 Go 进程授权？
mysqldump是以运行 Go 程序的系统用户身份连库的，不是以代码里的user=root就真能连——得确认该系统用户有对应 MySQL 账号+密码+host 权限（比如'root'@'localhost'和'root'@'127.0.0.1'是两个账号） - 密码含特殊字符（如
@、/、空格）？别拼进命令参数，改用--defaults-extra-file写临时配置文件，更安全
备份时加 --single-transaction 和 --skip-lock-tables 不是可选项
默认 mysqldump 会锁表，对线上业务就是阻塞。InnoDB 表必须开事务一致性快照，否则备份中途写入会导致数据不一致。
-
--single-transaction：只对 InnoDB 有效，启动一个 REPEATABLE READ 事务，全程读取快照，不锁表 -
--skip-lock-tables：显式关掉FLUSH TABLES WITH READ LOCK，配合上一条用；如果混用 MyISAM 表，这条不能加，但你真还在用 MyISAM 吗？ - 别信“我库小，无所谓”——哪怕只有几百行，只要备份期间有
UPDATE或INSERT，就可能漏数据或报错
恢复时用 mysql 命令重定向比 exec.Command + StdinPipe 更稳
有人想用 Go 读取 SQL 文件再通过 mysql 的 StdinPipe() 流式导入，结果卡死或乱码。根本原因是 MySQL 客户端对 stdin 的缓冲和 EOF 判定很敏感，尤其遇到大文件或注释多的 dump。
- 老老实实用 shell 重定向：
exec.Command("mysql", "-u", user, "-p"+pass, db).CombinedOutput()配合cmd.Stdin = file可行，但更推荐写临时脚本调用：sh -c 'mysql -u... - SQL 文件开头带
SET NAMES utf8mb4？确保mysql客户端版本支持，5.7+ 没问题，5.6 要手动加--default-character-set=utf8mb4 - 恢复前要不要
DROP DATABASE？别让 Go 干这事——mysql命令不认DROP DATABASE IF EXISTS在 SQL 文件里执行，得拆成两步：先用mysqladmin或单独连一次删库，再导入
os/exec 的超时和错误捕获必须显式处理
mysqldump 卡住、网络抖动、磁盘满，都会让 cmd.Run() 一直挂起。默认没超时，Go 程序就僵在那里。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
context.WithTimeout包一层：cmd.Start() → cmd.Wait() → select { case -
cmd.CombinedOutput()返回的 error 是*exec.ExitError，要类型断言才能拿到真实退出码：if xerr, ok := err.(*exec.ExitError); ok { xerr.ExitCode() }—— 退出码 2 通常是连接失败，4 是权限拒绝 - 输出日志别只打
err.Error()，string(out)和string(errOut)都得记，mysqldump的报错全在 stderr 里，比如mysqldump: Got error: 1045: Access denied for user...
mysqldump 当成一个黑盒外部服务来对待：它有自己的用户体系、字符集逻辑、锁行为和错误码语义。漏掉任意一环，备份看起来成功了，恢复时才发现主键重复、时间戳错乱、中文变问号。 
