Plugin 中不能直接传递 Go 指针
Go 的 plugin 包不支持跨模块传递 Go 运行时对象（包括结构体指针、切片、map、channel 等），因为 plugin 加载后运行在独立的符号空间，且 GC 不感知对方堆上的内存。你传一个 *MyStruct 进 plugin 函数，大概率触发 panic 或读到垃圾数据。
常见错误现象：panic: reflect.Value.Convert: value of type *main.MyStruct cannot be converted to type *plugin.MyStruct，或者更隐蔽的段错误、随机字段为零值。
- plugin 编译时的类型和主程序中的同名类型，在 runtime 看是完全不同的类型（哪怕字段一模一样）
- 即使用
unsafe.Pointer强转，也无法绕过类型系统校验和 GC 隔离 - 函数签名里出现任何非基本类型的指针（如
*int、*[]byte）都会失败
只能传 C 兼容类型或序列化数据
plugin 接口只认 C ABI：基础类型（int、uint64、uintptr）、C 字符串（*C.char）、C 数组指针（*C.int），以及由它们构成的 C struct（需用 //export + C.struct_XXX 声明）。
实际做法是把数据“扁平化”再传过去：
立即学习“go语言免费学习笔记（深入）”；
- 用
C.CString()传字符串，记得在 plugin 里C.free() - 用
unsafe.Pointer(&slice[0])传字节切片，同时额外传长度（len(slice)） - 复杂结构体先
binary.Write到[]byte，再传指针+长度；plugin 侧反序列化 - 避免在 plugin 内长期持有主程序传来的指针——它可能被 GC 回收，且 plugin 无法调用 Go GC API 保活
plugin 内部 new 出来的 Go 指针不能返回给主程序
反过来也不行：plugin 里 &someLocalVar 或 &MyStruct{} 得到的指针，一旦返回给主程序调用方，主程序无法安全解引用。Go runtime 不允许跨模块访问对方堆内存。
典型错误场景：plugin 导出函数返回 *Config，主程序试图读 cfg.Timeout，结果 panic 或返回零值。
- 返回值必须是 C 兼容类型，或通过
uintptr传回“句柄 ID”，主程序查表映射到本地对象 - 若必须共享状态，改用全局变量 + 互斥锁 + C 函数封装读写（但注意：plugin 和主程序的
sync.Mutex不互通，得用C.pthread_mutex_t） - plugin 内创建的 channel / goroutine 与主程序完全隔离，无法直接通信
替代方案比硬啃 plugin 指针更可靠
真要跨模块共享内存或调用逻辑，plugin 本身限制太多，容易掉坑。更稳的路是：
- 改用进程间通信：主程序起 HTTP/gRPC server，plugin 作为 client 调用；或用
os.Pipe()+ protobuf - 用
cgo把核心逻辑编译成 .so，主程序以 C 方式加载（绕过 Go plugin 类型检查） - 放弃动态加载，改用接口注入：定义
type Processor interface { Process([]byte) error }，plugin 编译进主程序，靠 build tag 控制启用
真正难的不是怎么传指针，而是说服自己——Go 的 plugin 不是 DLL，它没打算让你共享内存。接受这个前提，选型就清楚了。
