goland无法调试plugin.open加载的插件代码，因插件.so的dwarf调试信息未被delve识别，仅主程序符号可调试；替代方案是日志+接口契约+独立运行插件验证。
GoLand 无法直接调试 plugin.Open 加载的 Go 插件代码——这不是配置问题，而是 Go 插件机制本身的限制决定的。
plugin.Open 加载的代码根本不在 GoLand 的调试符号范围内
Go 插件（.so 文件）是独立编译的二进制模块，其 DWARF 调试信息在加载时不会被主程序的调试器（Delve）识别。即使你在插件源码里打了断点，GoLand 启动后 attach 到进程，也看不到插件里的源码行、变量或调用栈。
- Delve 只能调试主程序（即
go build生成的可执行文件）的符号；插件的符号表是隔离的、未注入调试会话的 -
plugin.Open本质是dlopen()，不是源码级嵌入，IDE 没有途径将插件的.go文件与运行时地址映射起来 - 你看到的 “插件函数被调用” 只是主程序通过
plugin.Lookup拿到函数指针并跳转执行，中间没有调试器可介入的上下文
替代方案：用日志 + 主程序断点 + 接口契约缩小排查范围
既然不能单步进插件函数，就只能把调试重心移到“通信边界”和“可观察行为”上：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 在插件导出的函数入口加
log.Printf("plugin: Init start, args: %+v", args)—— 日志必须显式 flush，避免缓冲丢失 - 主程序调用
plugin.Lookup("Init")后、类型断言前，打个断点，检查返回值是否为nil；断言后立刻打印fmt.Printf("got plugin func: %p", initFunc)确认非空 - 如果插件实现了一个接口（如
type Processor interface { Process() error }），确保该接口定义在**独立的公共 module** 中，主程序和插件都import它；否则类型断言会 panic，且错误发生在运行时，不是编译期 - 避免在插件里做任何不可见副作用（比如静默修改全局 map、启动 goroutine 但不暴露控制句柄）——这类行为只能靠日志或外部观测（pprof / /debug/pprof/goroutine）发现
Linux 下唯一可行的“类调试”手段：用 delve 手动 attach + symbol 文件硬凑
严格来说这不是 GoLand 支持的流程，但极少数场景下可临时应急：
- 插件编译时加
-gcflags="all=-N -l"（禁用内联+优化），并保留.go源码路径与.so文件在同一台机器 - 主程序启动后，用
ps aux | grep yourapp找到 PID，再用命令行dlv attach <pid></pid> - 在 dlv CLI 里手动
source ./path/to/plugin.go（仅当路径完全匹配且无 GOPATH 干扰时才可能成功），然后break plugin.go:12 - 成功率极低，且 GoLand 的 GUI 调试器完全不感知这些操作；一旦插件 reload（
plugin.Open再次调用），所有断点失效
真正要调试插件逻辑，得把它当成独立程序跑：删掉 package main 外壳，改成普通包，写一个临时 main.go 直接 import 并调用，这时 GoLand 全功能调试可用。插件化只是部署形态，开发阶段不该绕过这个最直接的验证路径。
