Go1.11版本中vendor机制是否已被弃用？
Go1.11版本中vendor机制是否已被弃用？ 我的大多数同事都不提交vendor文件夹。随着go1.11（模块）的出现，vendor的未来会怎样？ 提交vendor最大的好处是在CI流水线上节省时间，无需在所有步骤中都重新填充vendor。
也许像athens这样的内部缓存（https://github.com/gomods/athens）可以解决这个问题。
你们对此有什么看法？
我认为 vendor 文件夹的一个优点是模块无法提供的：如果某个库的作者决定从 GitHub（或任何托管位置）删除它，你仍然保留了一份副本，之后可以决定迁移到其他方案（或继续使用这个已弃用的库）。
在Go 1.11及更高版本中，vendor机制并未被官方弃用，但它与Go模块（Go Modules）的集成方式发生了变化。vendor目录仍然可以用于依赖管理，但Go模块已成为推荐的依赖管理方案。以下是一些关键点：
-
vendor机制的状态：vendor目录在模块模式下仍然受支持，但不再是必需的。Go模块通过
go.mod和go.sum文件管理依赖，并默认从模块代理或版本控制系统下载依赖。vendor目录可以作为可选方式，用于离线构建或确保构建一致性。 -
使用vendor的优势：如你所述，在CI流水线上使用vendor可以避免重复下载依赖，节省时间并提高可靠性。你可以通过
go mod vendor命令生成vendor目录，并将其提交到版本控制中。 -
Go模块与vendor的结合：在Go 1.11+中，如果项目根目录存在vendor目录，Go工具链会优先使用vendor中的依赖，而不是远程下载。这允许你在模块项目中继续利用vendor的好处。
-
替代方案：像Athens这样的内部模块代理确实可以解决依赖缓存问题，通过在本地或内部网络缓存依赖，减少CI流水线的下载时间。但vendor机制更简单直接，无需额外基础设施。
示例代码：在Go模块项目中使用vendor：
- 初始化模块（如果尚未初始化）：
go mod init example.com/myproject - 添加依赖并生成vendor目录：
go mod tidy go mod vendor - 提交vendor目录到版本控制，CI流水线可以直接使用本地依赖。
总之，vendor机制在Go 1.11+中未被弃用，但Go模块是未来方向。根据项目需求，你可以选择继续使用vendor或迁移到模块代理方案。
