Go微内核应使用接口而非函数指针实现多态：接口提供编译期类型检查、统一调用语法和安全动态绑定，而函数指针丢失参数统一性、增加运行时panic风险且破坏类型安全。
Go 语言本身不支持函数指针层面的多态调度，所谓“基于函数指针模拟多态”本质是绕开接口机制、手动维护函数表的权宜之计，在微内核场景下不仅没带来好处，反而破坏类型安全、增加维护成本。
为什么 func(*T) 不等于多态入口
把方法包装成 func(*T) error 类型变量并存入 map 或 slice，看起来像“注册行为”，但实际丢失了关键能力：
- 无法统一参数类型：
func(*A) error和func(*B) error是完全不同的类型，不能共用同一 slice（如[]func(interface{}) error），强行转成interface{}就退回反射或类型断言的老路 - 调用时必须显式传入具体类型实例，无法做到 “
obj.Do()” 这种统一语法，每处调用都要写f(&a)或f(&b)，逻辑分散 - 编译期零检查：如果某类型漏实现某个“函数指针槽位”，只有运行到那一行才 panic，而接口会在赋值时就报错
微内核里真正需要的不是函数指针，而是可插拔的行为契约
微内核关注模块解耦与运行时替换，比如驱动、调度器、IPC handler —— 这些不是靠一堆孤立函数拼起来的，而是靠明确定义的接口边界：
-
type Driver interface { Init() error; HandleIRQ(uint8) bool }—— 所有驱动都满足它，内核主循环只认这个接口，不 care 具体是PCIeDriver还是USBHostDriver -
type Scheduler interface { Schedule(runnable []Task) []Task }—— 替换调度算法只需提供新 struct，无需改调度主逻辑 - 模块注册用
RegisterDriver(Driver)，而非RegisterFunc("init", func(...))—— 前者带完整类型信息和方法集，后者只是裸函数地址
指针接收者 + 接口才是微内核里安全的“动态绑定”
结构体方法是否满足接口，取决于接收者类型是否匹配。微内核中常见陷阱：
立即学习“go语言免费学习笔记（深入）”；
- 定义接口要求
func(*Device) Start()，但实现时写了func(d Device) Start()—— 此时Device{}值无法赋给该接口，只有&Device{}可以；而内核初始化常需复用栈上小对象，强制取地址反而增加 GC 压力 - 误用空接口
interface{}当通用容器：比如var handlers []interface{}存各种 handler，后续调用前必须做h.(SpecificHandler).Do()，一旦类型断言失败就 panic，且 IDE 无法跳转、go vet 无法检查 - 嵌入导致方法冲突：两个基础接口都含
Close() error，但签名不同（一个返回error，一个返回bool），直接嵌入会编译失败 —— 微内核模块间依赖深，这类冲突比想象中更频繁
微内核的“极简”不在删减语法特性，而在克制地使用接口——每个接口只定义 2~3 个高内聚方法，让模块之间仅通过最小契约通信。函数指针那套 C 风格的 dispatch table，Go 用接口 + 编译期检查 + 运行时动态分发已经做得更稳、更轻、更易测。真要动手写微内核，第一件事不是造函数表，是先写好那几个核心接口的签名。
