GoLand不支持直接调试选中代码段，但可通过Run Context Configuration临时执行语法完整的表达式或语句序列，需确保无未声明变量、已导入依赖且项目已go mod tidy。
直接调试选中代码段而不是整个 main
GoLand 默认不支持“只运行几行代码”式的调试，但可以通过 Run Context Configuration（上下文运行配置）临时执行局部逻辑。关键前提是：这段代码必须能被 Go 的语法解析为独立可执行单元——比如一个函数调用、表达式或带 main 的小片段。
常见错误现象：Cannot run selected code: not a valid Go statement or expression。这通常是因为选中了不完整的语句（如只选了 fmt.Println 没选括号和参数），或包含未声明变量、未导入包的裸代码。
- 确保选中内容是语法完整的表达式或调用，例如
fmt.Sprintf("id=%d", 123)或strings.ToUpper("hello") - 不能选中
var x int单独一行——它不是可执行语句；但可以选中var x int; x = 42; fmt.Println(x)这样的多语句序列（用分号分隔） - 如果用了第三方包（如
github.com/sirupsen/logrus），必须确保当前文件已 import，且项目依赖已go mod tidy完成
打断点后如何单步进入函数内部
GoLand 的单步行为取决于函数是否内联、是否在当前模块内、以及是否启用了调试符号。默认情况下，step into（F7）只进入当前包内定义的函数；对标准库或外部包，会直接跳过（step over）。
想真正进入 fmt.Printf 或 json.Marshal 内部？不行——它们是编译器内联或无调试信息的预编译代码。但你可以进入自己写的函数、或本地 vendor 中的第三方代码。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 确认目标函数定义在当前项目路径下（非
$GOROOT或$GOPATH/pkg/mod） - 检查 Go SDK 是否启用调试信息：在
Settings | Go | Build Tags and Vendoring中，确保未勾选Build with -ldflags="-s -w"（该选项会剥离调试符号） - 如果函数被编译器内联（常见于小函数），加
//go:noinline注释强制不内联，再试step into
调试时变量值显示为空或 <not accessible>
这不是 bug，而是 Go 编译器优化导致的常见现象。尤其在 go build 默认开启的优化级别下（-gcflags="-l" 禁用内联，但不关其他优化），局部变量可能被寄存器暂存或重用，调试器无法读取原始值。
影响最明显的是：循环变量、短生命周期的中间值、返回值未显式赋给变量时的临时结果。
- 临时解决：在可疑变量后加一行
_ = yourVar，阻止编译器优化掉它 - 长期办法：调试时用
go build -gcflags="-N -l"构建（-N关闭优化，-l关闭内联），再通过Run | Edit Configurations→Go Build→Environment添加CGO_ENABLED=0 GOFLAGS=-gcflags="-N -l" - 注意：开启
-N -l后二进制体积变大、启动略慢，仅用于调试，不要用于生产构建
为什么修改代码后断点失效或跳到错误行
本质是源码与调试信息（debug info）不匹配。GoLand 调试器依赖编译产物中的 line number table，一旦你改了断点所在文件但没重新构建，旧的调试信息仍指向原位置。
典型场景：你在 handler.go 第 45 行打了断点，然后删了前面两行空行，再调试——断点实际停在新文件的第 43 行（原 45 行逻辑位置），但 IDE 显示仍在第 45 行，造成错觉。
- 每次修改含断点的文件后，务必触发一次构建（哪怕只是保存 + Ctrl+Shift+F10）
- 避免在调试中热重载（Live Edit）修改 Go 文件——它不触发重新编译，调试器会彻底混乱
- 如果断点变成灰色空心圆，说明未绑定到任何代码行，鼠标悬停会提示
Line is not executable或Source not found，此时需检查 GOPATH/GOMODCACHE 是否被清理、或是否在 symlink 路径下打开项目
