go mod vendor不能解决增量编译慢的问题，因其不加速构建，反而可能因解析vendor内全部依赖图及版本冲突fallback导致缓存失效；真正影响增量编译速度的是build cache复用、import优化、testdata/embed滥用及go.work冗余扫描。
Go mod vendor 不能解决增量编译慢的问题
直接执行 go mod vendor 并不会让 go build 变快，反而可能拖慢首次构建——因为 vendoring 后 Go 仍需解析全部 vendor 目录下的 go.mod 和依赖图，且 vendor 内部模块版本冲突时会触发隐式 fallback 到 $GOPATH/pkg/mod，导致缓存失效。
真正影响增量编译速度的，是 Go 的 build cache 机制是否被有效复用，以及项目中是否存在大量跨 package 的非必要 import 循环、未清理的调试代码（如 fmt.Println 或 log 调用）、或频繁变更的 const/variable 定义被上层 package 大量引用。
- 确认 build cache 是否启用：
go env GOCACHE—— 默认开启，但若 CI 环境清空了$HOME/.cache/go-build，每次都是冷缓存 - 避免在
main或高频变更包里 import 整个工具包（如github.com/xxx/utils），应拆出子包按需导入（如github.com/xxx/utils/stringutil） - 检查
go list -f '{{.Deps}}' ./...输出中是否有异常长的依赖链，尤其注意第三方 SDK 是否带了大量未使用的子模块（如某些云厂商 SDK 默认含全量服务 client）
用 go build -toolexec 配合 buildcache 加速单体构建
go build -toolexec 不是用来替代编译器的，而是让 Go 在调用 compile、asm、link 等底层工具前，先走你指定的 wrapper 脚本。这个特性可以用于拦截和缓存中间对象（.a 文件），绕过 Go 默认 build cache 对源码时间戳敏感的限制——比如你只改了一个 .go 文件但其他文件的 mtime 因 git checkout / IDE 自动保存而批量刷新，Go 会误判整个 package 需重编译。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 写一个轻量 wrapper（如 shell 脚本），对输入的
.go文件计算 SHA256（不含注释和空白行），生成稳定 key；查本地 object cache 中是否存在对应.a，存在则 cp 替换，不存在则 exec 原命令并存档 - 仅对稳定、低频变更的 core 包启用该机制（如
model/、domain/），不建议全局启用——否则会掩盖真实依赖问题 - 注意：Go 1.21+ 对
-toolexec的调用路径做了 stricter validation，wrapper 必须可执行且返回值符合 Go 工具链预期，否则报错exec: "xxx": executable file not found
大型单体项目必须禁用 go.work（除非真要多模块协同开发）
很多团队看到 Go 1.18 引入 go.work 就立刻在根目录初始化，结果发现 go build 变慢、VS Code Go 插件跳转卡顿、go list 超时。根本原因是 go.work 会让 Go 工具链反复扫描所有 replace 和 use 指向的目录，即使那些目录下只有 go.mod 没有实际代码，也会触发冗余 module resolution。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
适用场景其实非常窄：
- 你正在同时开发主项目 + 2 个以上独立开源库，并需要它们实时互引（不是 vendor 或 proxy）
- 你明确知道每个
use路径下都有合法go.mod，且无嵌套go.work - CI 构建流程已统一关闭
GOWORK环境变量（否则go build会自动加载，引发不可控行为）
绝大多数单体项目，删掉 go.work 文件 + unset GOWORK 后，go build -v 日志中 “resolving imports” 阶段耗时下降 30%~70%。
增量编译慢的真凶往往是 testdata 和 embed.FS
当你改一行业务逻辑，却等待 8 秒才看到 build 完成，大概率不是 Go 编译器慢，而是 testdata/ 下的几百 MB JSON/YAML 文件被 embed 进了某个包，或者 go test 扫描时递归加载了这些文件——Go 的 embed 是编译期打包，只要所在 package 被 import，整个 embed.FS 就参与构建；而 testdata/ 目录虽不参与 build，但 go list 仍会遍历它来判断是否含测试文件。
对策很直接：
- 把大体积测试数据移出
testdata/，放到项目外（如../test-data/），并在 test 中用绝对路径或环境变量加载 - 如果必须用
embed，不要 embed 整个目录：//go:embed assets/*.png比//go:embed assets安全得多 - 在
go.mod里加exclude github.com/xxx/legacy-testdata（如果该路径已被误引入依赖图）
一个典型信号是 go build -x 输出中出现大量 compile -o $WORK/xxx.a -trimpath $WORK 后紧跟数秒停顿——那基本就是 embed 或 testdata 扫描卡住了。
