vscode调试时vendor目录被忽略的典型现象是断点无法进入vendor中的第三方源码，或跳转到module cache而非vendor路径，根本原因是vscode调用dlv时未传递-mod=vendor标志，需在.vscode/settings.json中配置"go.toolsenvvars": {"goflags": "-mod=vendor"}并重启vscode。
VSCode 调试时 vendor 目录被忽略的典型现象
你在 VSCode 里按 F5 启动调试，断点进不了 github.com/sirupsen/logrus 的源码，或者跳转到的是 $GOPATH/pkg/mod 下的缓存版本，而不是你 vendor/ 里的那份——这说明 VSCode 的 Go 扩展没走 -mod=vendor 模式，而是默认用了 module 模式。
根本原因不是 VSCode 本身的问题，而是它调用 dlv（Delve）时没传正确的构建标志。VSCode 默认执行的是 go build，不加任何 flag，vendor/ 就只是个普通文件夹，完全不会被加载。
- Go 扩展（golang.go）在 2025 年后已支持自动识别
go.mod和vendor/，但不会自动启用 vendoring - 即使你本地运行
go build -mod=vendor成功，VSCode 调试仍可能绕过它 - 如果你用
replace指向本地 fork，但没配GOFLAGS="-mod=vendor"，VSCode 可能拉错版本，导致调试行为和构建结果不一致
让 VSCode 调试真正使用 vendor 目录的配置方法
必须显式告诉 VSCode：调试构建阶段要加 -mod=vendor。这不是改 launch.json 里的 args，而是改构建参数本身。
在项目根目录下创建或编辑 .vscode/settings.json，加入：
{
"go.toolsEnvVars": {
"GOFLAGS": "-mod=vendor"
}
}
这个设置会让所有 Go 工具（包括 go build、go test、dlv 启动前的构建步骤）都带上该 flag。比在 launch.json 里硬编码 env 更可靠，因为后者只影响 dlv 进程本身，不控制构建阶段。
- 不要用
GO111MODULE=off：它会退回到 GOPATH 模式，彻底无视go.mod和vendor/ - 确保
go.mod存在且非空：哪怕只是module example.com/foo，否则-mod=vendor会被静默忽略 - 如果项目用了
replace，确认vendor/modules.txt已更新（即跑过go mod vendor），否则 dlv 加载的符号路径会和实际源码不匹配
调试第三方库源码时 vendor 目录的路径映射问题
你能在 vendor/github.com/sirupsen/logrus 里设断点，但调试时提示 “source not found” 或跳转到空白页？这是 Delve 找不到源码路径映射导致的。
VSCode 的 Go 扩展默认依赖 dlv 自动解析路径，但在 vendoring 场景下，模块路径（如 github.com/sirupsen/logrus）指向的是 vendor/ 下的副本，而 dlv 的符号表仍按 module path 记录——只要 vendor/ 结构完整、modules.txt 准确，它就能定位。但有两个常见干扰项：
-
vendor/**/*_test.go或vendor/**/testdata/被误提交：它们会污染dlv的源码索引，导致路径解析失败；应在.gitignore中显式排除 - 手动修改过
vendor/下的代码（比如 patch 了某行日志）：下次go mod vendor会覆盖，但dlv缓存的调试信息可能还指向旧行号，造成断点偏移 - IDE 缓存未刷新：改完
settings.json后，务必重启 VSCode 窗口（不是重载窗口），否则GOFLAGS不生效
为什么 go test -mod=vendor 在终端成功，但 VSCode 测试任务失败
VSCode 的测试任务（通过 Go: Test Package 命令触发）默认不继承 GOFLAGS，除非你显式配置测试命令模板。
解决办法是，在 .vscode/settings.json 中补充：
"go.testFlags": ["-mod=vendor"]
这样所有测试操作（包括右键菜单、命令面板、测试装饰器）都会带上该 flag。
- 别依赖
go.testEnvFile：它只注入环境变量，不控制go test的命令行参数 - CI 构建用
go test -mod=vendor成功 ≠ VSCode 测试一定成功：本地 IDE 和 CI 的执行上下文隔离，flag 必须各自配 - 如果测试中用了
//go:build ignore或构建约束，确认vendor/下对应包没被意外剔除（go mod vendor默认尊重这些约束）
最常被忽略的一点：vendor 目录一旦启用，就不再是“可选附件”，而是构建契约的一部分。VSCode 调试器不会替你做一致性校验——go mod vendor -v 显示有差异，或 vendor/modules.txt 比 go.mod 老，调试时就可能加载错版本，且错误往往静默发生，只表现为断点不命中或变量值异常。
