VSCode调试时init函数断点常被忽略，因Delve在main入口后才完全接管控制流，init由运行时直接调用且不入常规调用栈；应改用日志+时间戳验证真实执行顺序。
VSCode 里看到的 init 执行顺序，和实际运行时一致——但调试器可能跳过部分 init，导致你以为“没执行”或“顺序乱了”。
为什么 VSCode 调试时 init 看不见、断点不命中
Go 的 init 函数在程序启动早期由运行时直接调用，不经过常规函数调用栈；VSCode 的 Delve 调试器默认只在 main 入口之后才完全接管控制流。
- 断点打在
init函数里，Delve 可能尚未完成初始化，断点被忽略（尤其在多模块、replace或go.work场景下） - VSCode 的“调试控制台”输出有时滞后或截断，
log.Println("in init")可能比main的输出晚出现，误判为“后执行” - 如果模块用了
replace指向本地路径，而该路径下文件名排序与主模块不一致（比如z_db.govs01_db.go），VSCode 启动时加载的编译顺序可能和go run .不同 - 解决办法：不用断点，改用日志 + 时间戳 —— 在每个
init开头加log.Printf("[init %s] %v", "a.go", time.Now().UnixMilli())
多模块（go.work）下 init 顺序为什么和单模块不一致
Go 工具链对 go.work 中列出的模块，会合并依赖图并重新拓扑排序；模块间隐式依赖（比如 A 模块 import B，B 模块又 import C）会被完整展开，但模块内文件排序仍按各自目录下的字典序，而非工作区整体排序。
- 现象：模块
foo的config.go和模块bar的db.go都有init，但你发现bar的先跑 —— 实际是因为foo依赖了bar的某个导出类型，触发了bar提前初始化 -
go.work不改变单个模块内文件名排序规则，但会改变跨模块的依赖解析起点；若模块未被显式引用（比如只import _ "foo"但没用任何符号），Go 1.22+ 可能直接跳过其init - 验证方式：运行
go list -deps -f '{{.ImportPath}}' . | sort，看依赖链是否和你预期一致；再用go build -gcflags="-S" main.go 2>&1 | grep -i "CALL.*init"查汇编里实际调用顺序
VSCode 启动配置里哪些设置会干扰 init 行为
VSCode 的 .vscode/launch.json 若配置不当，会让 Delve 加载阶段绕过部分初始化逻辑，或强制使用不同构建模式。
-
"mode": "test"或"mode": "exec"时，Delve 可能跳过某些包的init（尤其是未被测试代码直接引用的包） -
"env": {"GODEBUG": "mmap=1"}类调试环境变量，可能触发 runtime 初始化提前，影响init中依赖runtime状态的代码（比如debug.SetGCPercent） - 错误配置：
"args": ["-ldflags=-s"]本身不影响init，但若同时启用了"trace": true，Delve 会在 symbol 加载完成前就开始跟踪，漏掉最早一批init - 安全做法：调试 init 相关问题时，删掉所有非必要
env和args，用默认"mode": "auto"，并在main开头加一行runtime.GC()强制触发一次 GC，确认所有init已完成
真正容易被忽略的点是：VSCode 调试器看到的“执行顺序”，本质是 Delve 的 hook 注入时机，不是 Go 运行时的真实顺序；想确认真实行为，永远以 go run 输出为准，而不是调试器里的 call stack 或断点命中顺序。
