goland 不支持 memorysanitizer（msan），因其依赖 llvm 编译器插桩，而 goland 默认使用标准 go 编译器（gc）且无 gllgo 集成；msan 要求全链路（含标准库）均经 msan 编译，这在 go 生态中不可行。
GoLand 本身不支持 MemorySanitizer（MSan），gllgo 才支持，且仅限于 llgo 编译器生态。你如果在 GoLand 里点「Profile」或勾选「Enable profiling」，哪怕选了 Memory，那也只是 Go 自带的 pprof heap profile，和 MSan 完全无关。
为什么 GoLand 无法配置 MemorySanitizer
MemorySanitizer 是 LLVM 生态的工具，依赖编译器在 IR 层插桩跟踪未初始化内存的传播路径。标准 Go 编译器（gc）完全不支持 MSan；只有基于 LLVM 的 gllgo（llgo 的命令行工具）通过 -fsanitize=memory 参数启用它。GoLand 的构建系统默认调用 go run 或 dlv，不会触发 gllgo 流程，也没有对应 UI 选项。
- GoLand 的「Run Configuration」里所有 profiling 选项都面向 Go 原生运行时（
net/http/pprof或 CPU/heap trace），不是 sanitizer -
gllgo -fsanitize=memory编译出的是可执行文件，不是 Go 源码直接运行，无法被 GoLand 的 debugger 或 profiler 识别 - MSan 要求所有依赖（包括 libc、runtime）都用 MSan 编译，而 Go 标准库不可能满足该条件——这是根本性限制
想用 MemorySanitizer，只能走命令行 + gllgo
如果你已安装 gllgo（llgo 工具链），且代码是纯 Go（无 cgo），可以手动编译并运行：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 确保代码不含
cgo：MSan 不支持混合 ABI，//go:cgo或#include会直接报错 - 用
gllgo -fsanitize=memory -g your_program.go -o your_program编译 - 运行前设置环境变量：
export MSAN_OPTIONS="halt_on_error=1:abort_on_error=1"，避免静默失败 - 运行
./your_program，一旦读取未初始化内存（如局部 struct 字段未赋值就传参），会立即 crash 并打印栈和变量名
注意：gllgo 目前对泛型、反射、unsafe.Pointer 转换支持有限，遇到 panic: unimplemented 就得降级或绕开。
常见误判和替代方案
MSan 对“未初始化”的定义比直觉更严格：比如 var x [1024]byte 在栈上分配后，整个数组内容是未定义的（即使没显式写），访问任意 x[i] 都可能触发报告——这不是 bug，是设计如此。容易和真正的问题（如 malloc 后未 memset）混淆。
- 真要查未初始化内存，优先用
go vet -shadow查变量遮蔽，staticcheck查 nil 指针解引用 - 对 C/C++ 互操作部分，用 GCC/Clang 的
-fsanitize=memory更可靠 - Go 原生场景下，
go test -race和go run -gcflags="-d=checkptr"是更实际的防线
MSan 在 Go 生态里是边缘工具，连 llgo 官方文档都标注“experimental”。别指望它像 ASan 那样稳定，更别试图把它塞进 IDE 流程里——那只会浪费两小时配环境，最后发现根本跑不起来。
