heroku 官方 go 构建包已弃用 godeps 支持，需将依赖迁移至 vendor 目录（如使用 govendor、glide 或 dep），否则构建时会因无法解析第三方包而失败。
heroku 官方 go 构建包已弃用 godeps 支持，需将依赖迁移至 vendor 目录（如使用 govendor、glide 或 dep），否则构建时会因无法解析第三方包而失败。
Heroku 的 Go 构建包（heroku-buildpack-go）自 Go 1.6 起正式转向基于 vendor/ 的标准依赖管理机制，Godeps 已被标记为废弃（deprecated）。尽管构建包中仍保留部分向后兼容逻辑，但实际运行中（尤其在 Go 1.7+ 环境下）它不会自动执行 godep restore，也不会将 Godeps/Godeps.json 中声明的依赖注入 $GOPATH/src —— 这正是你遇到 cannot find package "github.com/Sirupsen/logrus" 等错误的根本原因。
✅ 正确解决方案：迁移到 vendor 目录
Heroku 构建流程会按优先级自动识别以下 vendor 工具配置文件，并执行对应依赖还原：
| 工具 | 配置文件 | Heroku 支持状态 |
|---|---|---|
| govendor | vendor/vendor.json |
✅ 原生支持（默认启用） |
| glide |
glide.yaml + glide.lock
|
✅ 原生支持 |
| dep（已归档，不推荐新项目） |
Gopkg.toml / Gopkg.lock
|
✅ 曾支持（v78+），但 dep 已停止维护 |
| Godeps | Godeps/Godeps.json |
⚠️ 仅限极旧 Go 版本（当前不生效 |
? 提示：无需手动提交庞大的
vendor/目录到 Git（除非你选择govendor的-no-vcs模式）。现代工具（如 glide、dep）默认只提交锁文件，Heroku 构建时会自动拉取并解压依赖到vendor/。
? 推荐操作步骤（以 govendor 为例）
-
安装 govendor
go install github.com/kardianos/govendor
-
从 Godeps 迁移（自动转换）
Golang Google Wire下载在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
# 在项目根目录执行（确保已存在 Godeps/Godeps.json） govendor init govendor migrate -v Godeps/Godeps.json
-
验证 vendor 状态
govendor list +missing # 检查缺失依赖 govendor list +unused # 检查冗余依赖
-
提交关键文件
git add vendor/vendor.json git commit -m "chore: migrate from Godeps to govendor" git push heroku master
✅ 此时 Heroku 将检测到 vendor/vendor.json，自动运行 govendor sync，并在构建时正确设置 $GOPATH，使 go install 成功解析 github.com/Sirupsen/logrus 和 github.com/gin-gonic/gin。
⚠️ 注意事项与最佳实践
-
避免混合工具：不要同时保留
Godeps/和vendor/，清理无用目录：rm -rf Godeps vendor/.git git rm -r Godeps
-
Go 版本显式声明：在项目根目录添加
.godir（内容为go1.7.3）或通过 Heroku 配置设置：heroku config:set GOVERSION=go1.7.3
-
日志包路径变更提醒：
github.com/Sirupsen/logrus已迁移至github.com/sirupsen/logrus（小写s）。若你的代码仍引用大写路径，请同步更新导入语句，否则即使 vendor 成功也会编译失败。 -
替代方案对比：
-
glide：生态成熟，支持复杂依赖约束，推荐中大型项目； -
go mod（Go 1.11+）：当前最推荐，但需升级 Go 版本并启用模块模式（Heroku 自 v85 起全面支持）。只需go mod init+go mod tidy，提交go.mod和go.sum即可，无需vendor/。
-
✅ 总结
Godeps 在 Heroku 上失效是 Go 生态演进的必然结果。唯一可靠且符合平台规范的做法是迁移到 vendor 方案（govendor/glide）或直接升级至 Go Modules。迁移成本低、自动化程度高，且能显著提升构建稳定性与团队协作一致性。切勿尝试“绕过 vendor 提交依赖源码”或降级 Go 版本——这违背 Heroku 最佳实践，也增加维护风险。
