go mod tidy不能自动同步远程版本，因为它只同步本地go.mod与代码import的一致性，不主动拉取远程变更；必须先git pull获取最新的go.mod和go.sum，再执行go mod download或go build才能下载声明的依赖版本。
go mod tidy 为什么不能自动同步远程版本？
它只保证本地 go.mod 和代码 import 一致，不拉取远程仓库最新变更。比如同事提交了新依赖但没 push go.mod 和 go.sum，你 go mod tidy 不会发现——因为本地没改 import，工具就认为“一切正常”。
真正同步依赖版本的起点是 Git，不是 Go 命令。
- 必须先
git pull origin main拉下最新的go.mod和go.sum - 再运行
go mod download（或go build自动触发），才能下载go.sum里声明的、且未缓存在本地的模块版本 -
go mod verify应该在 CI 或本地手动跑一次，校验go.sum哈希是否匹配实际下载内容——防止文件被篡改或缓存污染
多人同时改依赖时，如何避免 go.sum 冲突？
冲突本身不可怕，可怕的是合并后 go.sum 缺行或哈希错位，导致别人 go build 直接失败。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 不要手动编辑
go.sum：它由 Go 工具链自动生成，任何手改都会被go mod tidy覆盖或报错 - 遇到
go.sum合并冲突，删掉冲突标记，保留双方所有行（go mod tidy会重生成，但前提是go.mod已正确合并） - 合并前先
go mod tidy本地清理，确保go.mod是干净的；再git add go.mod，让go.sum在下次go build时自动更新 - CI 中加一步
go mod tidy -v && git diff --exit-code go.mod go.sum，有差异就失败——强制所有人提交前 tidy
私有模块更新后，本地为什么还用旧版？
常见于 git.company.com/internal/lib 这类路径。Go 默认走 GOPROXY，但私有模块需要绕过代理，否则拉不到最新 commit。
- 确认
GOPRIVATE=git.company.com已设（不是git.company.com/*，通配符在 Go 1.19+ 才支持） - 私有模块升级后，需显式运行
go get git.company.com/internal/lib@main（或具体 commit hash），不能只靠go mod tidy - 如果模块用了
replace指向本地路径，协作时必须删掉——否则别人go build会找不到路径 -
go list -m -f '{{.Version}}' git.company.com/internal/lib可查当前解析出的版本，比看go.mod更准
tools.go 修改后，为什么 pre-commit 还用旧版 linter？
因为 tools.go 只是声明，不自动安装。团队成员各自运行 go install 的时机和顺序不同，就会导致工具版本不一致。
- 统一要求每次
tools.go变更后，执行go install ./... && go mod tidy（注意是./...，不是./） -
go install默认装到$GOBIN，必须确保所有人的$GOBIN在PATH最前面，否则可能命中系统旧版 - pre-commit hook 脚本里别写死
golangci-lint路径，直接调用命令名——让它走 PATH 查找 - VS Code 的 Go 扩展默认从 PATH 启动工具，PATH 错位会导致保存格式化静默失效，这点容易被忽略
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
