goland调试时delve环境变量由ide控制，主要通过运行配置的environment variables字段或help→edit custom properties中dlv.env设置；关键变量包括goroot、goexperiment和delve_log。
Delve 调试时的环境变量由谁控制
GoLand 启动调试会话时，dlv 进程本身不读取 GoLand 的 IDE 环境变量（比如你改了 GOPATH 或 GOBIN），而是继承自 GoLand 主进程启动时的 shell 环境。也就是说：你手动在终端里能 dlv version 成功，不代表 GoLand 一定能调通——它可能根本没加载你的 ~/.zshrc 或 Windows 系统 PATH。
GoLand 中真正生效的 Delve 环境变量位置
GoLand 不提供“为 dlv 单独设环境变量”的 UI 入口，但支持两种方式注入：
- 在
Run > Edit Configurations...里选中你的调试配置 → 展开 Environment variables 字段 → 填写如GO111MODULE=on;CGO_ENABLED=0（注意用分号分隔，Windows）或冒号（macOS/Linux） - 更底层、更可靠的方式：在
Help > Edit Custom Properties中添加dlv.env=GO111MODULE=on;CGO_ENABLED=0—— 这个配置会透传给所有dlv子进程，包括dlv debug和dlv exec模式
⚠️ 注意：dlv.env 是 Goland 私有配置项，不是 Delve 自身的环境变量；它只在 Goland 启动 dlv 时生效，命令行直接运行 dlv 不受此影响。
哪些环境变量对 Delve 调试实际起作用
绝大多数场景下，你**不需要**额外设置 Delve 专属环境变量。但以下三个例外情况必须留意：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
GOROOT：若项目用了非默认 Go 版本（比如多版本共存），且 Goland 没正确识别，需在调试配置中显式指定，否则dlv可能链接错 runtime 符号，导致断点失效或panic: proc.NewBinaryInfo -
GOEXPERIMENT：调试启用实验性特性的代码（如fieldtrack）时，必须让dlv进程看到该变量，否则无法解析新字段布局 -
DELVE_LOG：仅用于排障，设为1或2可输出 dlv 内部 gRPC 通信日志，路径默认在/tmp/dlv-*.log（Linux/macOS）或%TEMP%\dlv-*.log（Windows）
其他如 GOPROXY、GOINSECURE 对调试过程无影响——它们只参与 go build 阶段，而 Delve 的 debug 模式会在内部调用 go build -gcflags="all=-N -l"，此时已跳过 module 下载环节。
验证环境变量是否真的传给了 dlv 进程
最直接的办法是看进程树和实际 env：
- 启动调试后，在终端执行：
ps aux | grep dlv（macOS/Linux）或tasklist /fi "imagename eq dlv.exe"（Windows），找到对应 PID - 再用
cat /proc/[pid]/environ | tr '\0' '\n'（Linux）或PowerShell -Command "(Get-Process -Id [pid]).StartInfo.EnvironmentVariables"（Windows）查看完整环境列表 - 重点确认
GOROOT、GO111MODULE是否与你预期一致；若缺失，说明dlv.env没生效或 Run Configuration 里填错了格式
别依赖 dlv version 输出判断——它只反映 dlv 自身构建时的环境，不是运行时调试会话的环境。
