go mod init 报“go.mod already exists”是因为目录已存在该文件，属保护机制；需先删除旧文件再执行初始化。
go mod init 初始化模块时为什么报错“go.mod already exists”
说明：当你在已有 go.mod 文件的目录下重复执行 go mod init，Go 会直接拒绝并报这个错误。这不是 bug，而是 Go 模块系统的保护机制。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认当前目录是否已存在
go.mod（可用ls go.mod检查） - 如需重置模块配置，先删掉旧的
go.mod和go.sum，再运行go mod init your-module-name - 模块名不强制要求与代码仓库路径一致，但建议保持一致，否则后续
go get引入时容易混淆版本解析逻辑
go get 引入包后为什么 import 不生效或提示 “no required module provides package”
说明：这是 Go Modules 启用后的典型路径解析失败，根本原因是 import 路径与 go.mod 中记录的模块路径不匹配，或本地缓存未更新。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确保
GO111MODULE=on已启用（Go 1.16+ 默认开启，但某些 IDE 或 shell 环境可能覆盖） - 用完整模块路径执行引入，例如：
go get github.com/gin-gonic/gin@v1.9.1，而不是只写go get gin-gonic/gin - 引入后检查
go.mod是否新增对应行；若没变，可能是包已被其他依赖间接引入，此时可加-u强制更新：go get -u github.com/sirupsen/logrus - 如果仍报错，尝试
go mod tidy重新计算依赖图并下载缺失项
vendor 目录没生成或 go build -mod=vendor 失败
说明：Go 默认不自动生成 vendor，且 -mod=vendor 要求所有依赖必须已存在本地 vendor/ 中，否则构建中断。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 生成 vendor 前先确保
go.mod完整，然后运行go mod vendor -
go build -mod=vendor只跳过远程 fetch，不会自动补全 vendor；若 vendor 缺文件，构建直接报cannot find module providing package xxx - CI 场景中建议配合
go mod download预热缓存，而非强依赖 vendor —— vendor 主要用于离线或审计场景，不是日常开发必需
升级依赖时如何避免意外破坏现有功能
说明：Go 的语义化版本（semver）只是约定，第三方库未必严格遵守；一次 go get -u 可能拉入不兼容的大版本变更。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 升级前先看目标包的 CHANGELOG 或 release note，重点关注 v2+ 版本是否含 breaking change
- 用精确版本锁定，例如：
go get github.com/spf13/cobra@v1.8.0，避免@latest或@master - 升级后务必运行全部测试：
go test ./...；若项目有集成测试，也需覆盖关键路径 - 注意
go list -m all | grep xxx查看实际解析到的版本，有时间接依赖会覆盖你显式指定的版本
go.mod 文件写错一行路径，就可能导致整个依赖树失效，而且错误提示往往不直接指向根源。 
