增量备份go项目的关键是精准备份源码、go.mod/go.sum及必要产物，而非go环境；需用modtime().unixnano()与size()组合判断文件变更，并在manifest中记录go.mod时间戳和go.sum哈希，排除vendor/、./bin/等可重建目录。
增量备份不是备份 Go 本身，而是备份你的 Go 项目状态
Go 语言环境（GOROOT、GOPATH 或 go mod 缓存）本身不需要增量备份——它可重装、可重建。真正要增量备份的是：你正在开发的 Go 项目源码、依赖锁定（go.mod/go.sum）、构建产物（如 ./bin/）、本地测试数据或配置快照。误把 $GOCACHE 或 $GOPATH/pkg 当作“必须备份”对象，只会浪费空间且无恢复价值。
用 ModTime + Size 组合判断 Go 源文件是否变更
对 ./cmd、./internal、./api 等目录做增量扫描时，别只比对 os.Stat().ModTime()。某些场景下（比如 NFS 挂载、Windows 容器、CI 构建机时钟不同步），ModTime() 可能抖动 ±2s；而仅靠 Size() 会漏掉「内容不变但换行符/空格调整」这类修改。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：记录每个
.go文件的fi.ModTime().UnixNano()和fi.Size()，两者都一致才跳过 - 跳过
vendor/目录（若启用）或node_modules/（混用 JS 时），它们应由go mod vendor或npm install重建 - 排除
./bin/、./tmp/、./testdata/*.golden等生成物目录，除非你明确需要保留某次构建结果
备份 manifest 必须包含 go.mod 时间戳与 checksum
只存文件列表和时间戳的 backup_manifest.json 不够。Go 项目的核心一致性锚点是 go.mod 的内容和 go.sum 的校验和。如果备份时没记录这两者，恢复后 go build 可能拉取不同版本依赖，导致行为不一致。
- 在 manifest 中额外字段：
"go_mod_mtime": 1748005632123456789、"go_sum_hash": "sha256:abc123..." - 写入前用
os.ReadFile("go.mod")和sha256.Sum([]byte(...))计算 hash，而非依赖文件系统时间 - 若项目使用
replace或exclude，也一并序列化进 manifest，否则恢复时无法还原本地开发态
写入备份包时避免破坏 go mod download 缓存一致性
如果你的备份逻辑里调用了 os/exec.Command("go", "mod", "download") 并把下载的 zip 写入备份路径，就踩坑了：$GOCACHE 是全局共享的，直接复制 zip 包到目标机器后，go build 仍会去查缓存，而不是读你备份的 zip。
- 正确方式：备份只保留源码 +
go.mod+go.sum；恢复时执行go mod download重建缓存 - 如需离线恢复，用
go mod vendor生成vendor/目录，再把整个vendor/打包进备份（注意：vendor 目录需在 manifest 中标记为 “vendor_mode”: true） - 不要尝试备份
$GOCACHE路径——它含平台相关路径、临时解压痕迹，跨机器不可复用
go.mod/go.sum 的完整快照、以及明确区分「可重建」与「必须保留」的产物。其他所有东西，包括编译器二进制、SDK 缓存、IDE 配置，都不该进入增量备份范围。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
