go 库（无 main 包）不应将自身子包放入 vendor/ 目录；vendor/ 仅用于锁定外部依赖（如 github.com/xxx），而本地模块应通过标准目录结构组织，以保障可导入性、工具链兼容性与语义清晰性。
go 库（无 main 包）不应将自身子包放入 vendor/ 目录；vendor/ 仅用于锁定外部依赖（如 github.com/xxx），而本地模块应通过标准目录结构组织，以保障可导入性、工具链兼容性与语义清晰性。
在 Go 模块时代（Go 1.11+），vendor/ 目录的核心职责非常明确：它是一个只读的外部依赖快照目录，用于确保构建可重现性——但绝不用于存放项目自身的代码。
✅ 正确做法：将库的内部逻辑拆分为多个本地包，直接置于主模块根目录下的子目录中，例如：
mylib/
├── go.mod
├── README.md
├── server/ # package server
│ └── server.go
├── store/ # package store
│ └── db.go
├── testutils/ # package testutils
│ └── helpers.go
└── vendor/ # ← 仅含 github.com/..., golang.org/... 等外部依赖
├── github.com/stretchr/testify/
└── golang.org/x/net/此时，其他项目可通过 import "github.com/yourname/mylib/server" 正常引用，Go 工具链（go build, go test, go list）能天然识别这些路径，无需任何额外配置。
❌ 错误做法：把 server/ 或 store/ 移入 vendor/ 下（如 vendor/github.com/yourname/mylib/server）。这会导致：
- 导入路径失效（import "github.com/yourname/mylib/server" 将无法解析）；
- go mod tidy 和 go list 行为异常；
- IDE（如 VS Code + Go extension）失去符号跳转与自动补全能力；
- 违反 Go 的“一个包一个导入路径”原则，破坏模块语义。
⚠️ 特殊例外（极少需用）：仅当你的库需强制覆盖某外部依赖的特定 fork 分支，且该 fork 本身是独立仓库时，才应在 go.mod 中 replace 并 go mod vendor —— 此时 vendor/ 中出现的是该 fork 的远程路径，而非你自己的包。
? 总结：
- vendor/ 是“外部依赖保险箱”，不是“本地代码收纳盒”；
- 所有属于你库的 Go 包，必须位于模块根目录下（非 vendor 内），并通过清晰的子目录组织；
- 使用 go mod vendor 仅用于发布前锁定第三方依赖，日常开发中推荐关闭 vendor（GOFLAGS=-mod=mod）以获得最新依赖修复与工具支持。
