dlv
go install github.com/go-delve/delve/cmd/dlv@latest编译
go build -gcflags="all=-N -l" main.go
dlv exec ./main
golang把三方库copy到自己项目中
replace指令
https://go.dev/doc/tutorial/call-module-code
nvidia-container-toolkit没有使用replace也能做到
NVIDIA/nvidia-container-toolkit 如何使用 vendor 目录下的依赖
在 Golang 项目中，vendor 目录用于存储项目的依赖库副本，以确保项目在不同环境中的一致性。对于你提到的 NVIDIA/nvidia-container-toolkit 仓库，它使用了 vendor 目录下的 github.com/pelletier/go-toml 依赖，而没有在 go.mod 文件中使用 replace 指令，这是通过以下机制实现的：
- vendor 目录的存在
当执行 go mod vendor 命令时，Go 工具链会根据 go.mod 和 go.sum 文件中记录的依赖项和版本信息，将依赖库的代码复制到项目的 vendor 目录下。
这意味着，即使远程仓库的内容发生变化，只要项目中的 go.mod 和 go.sum 文件保持不变，vendor 目录下的依赖库副本也将保持不变。 - go.mod 文件中的依赖声明
在 go.mod 文件中，NVIDIA/nvidia-container-toolkit 仓库声明了对 github.com/pelletier/go-toml 依赖的依赖关系。
这通常是通过运行 go get github.com/pelletier/go-toml@特定版本 命令来完成的，该命令会自动更新 go.mod 和 go.sum 文件。 - 使用 vendor 目录进行构建
当在启用 Go Modules 的项目中进行构建或运行时（即设置了 GO111MODULE=on），Go 工具链会首先查找 vendor 目录中的依赖项。
如果在 vendor 目录中找到所需的依赖项，Go 工具链将使用该副本进行构建，而不会尝试从远程仓库拉取代码。 - 无需 replace 指令的原因
在 NVIDIA/nvidia-container-toolkit 的情况下，由于它已经将依赖项复制到了 vendor 目录中，并且 go.mod 和 go.sum 文件正确地记录了这些依赖项的版本信息，因此无需使用 replace 指令来覆盖远程仓库的路径。
replace 指令通常用于将远程依赖项替换为本地路径或替代的远程仓库路径，而在这个场景中，vendor 目录已经提供了所需的依赖项副本。
综上所述，NVIDIA/nvidia-container-toolkit 仓库通过正确地使用 vendor 目录和 go.mod/go.sum 文件来管理依赖项，从而实现了在不使用 replace 指令的情况下使用本地 vendor 目录下的 github.com/pelletier/go-toml 依赖。