最直接的本地调试方式是用 go mod edit -replace 修改 go.mod 添加 replace 指令，使构建使用本地模块代码；需确保本地路径含有效 go.mod 且 module 名匹配，替换后运行 go mod tidy，并配合 -gcflags="all=-N -l" 使用 dlv 调试。
用 go mod edit -replace 指向本地路径
调试依赖模块最直接的方式，是让当前项目在构建时使用本地修改后的模块代码，而非远程下载的版本。核心命令是 go mod edit -replace，它会改写 go.mod 中的依赖声明，添加 replace 指令。
-
go mod edit -replace github.com/user/dep=../local-dep：将远程模块github.com/user/dep替换为上层目录下的../local-dep（该路径必须包含有效的go.mod文件） - 执行后，
go build或go run会自动使用本地路径中的代码，包括断点、日志、修改逻辑 - 注意路径必须是绝对路径或相对于当前
go.mod所在目录的相对路径；不能是./xxx这种以.开头的路径（Go 不支持） - 替换后记得运行
go mod tidy确保依赖图一致，但不会把本地模块上传或发布
调试时 dlv 能否跳进本地替换的模块
可以，前提是源码路径与 replace 声明完全匹配，且 dlv 启动时未启用代码优化（如 -gcflags="all=-N -l"）。
-
dlv debug --headless --api-version=2 --accept-multiclient --continue启动调试器后，在 VS Code 或 CLI 中设置断点，能正常进入本地模块的函数 - 常见失败原因是：本地模块目录里没有
go.mod，或module名与replace左侧不一致（例如写了replace github.com/user/dep => ./dep，但本地go.mod里是module github.com/user/dep/v2） - VS Code 的
launch.json中建议显式加上："args": ["--gcflags", "all=-N -l"]
，避免内联或优化导致断点失效
go.work 是更干净的多模块调试方案
当你要同时调试多个本地依赖（比如 A 依赖 B，B 又依赖 C），用 replace 逐个写容易出错、难维护。go.work 提供工作区机制，更适合复杂本地调试场景。
- 在项目根目录运行
go work init，再用go work use ./a ./b ./c把多个模块纳入工作区 - 工作区内的模块会优先使用本地源码，无需
replace，也不影响各自独立的go.mod -
go run、go test、dlv debug全部自动识别工作区，调试体验和单模块无异 - 注意：Go 1.18+ 才支持
go.work，且必须确保所有模块的go.mod中module路径与你在go work use中指定的路径一致（例如不能混用./sub/dir和../other导致路径解析歧义）
调试完别忘了清理 replace 或 go.work
本地调试只是临时行为，提交前必须确认是否还残留调试配置，否则 CI 或协作者会拉不到依赖。
- 删掉
replace行后，运行go mod tidy恢复原始依赖版本 - 如果用了
go.work，调试结束可直接删掉go.work文件，不影响各模块自身go.mod - 一个易忽略的坑：某些 IDE（如 Go
land）会在后台缓存模块路径，即使删了
replace，仍可能继续读本地代码——此时需重启 IDE 或清空 Go module cache（go clean -modcache）
