抽象工厂在 Go 里根本不是靠 interface{} 或反射硬凑
Go 没有类继承，也没有构造函数重载，所谓“抽象工厂”本质是**一组返回具体结构体指针的函数集合**，配合接口约束行为。强行模仿 Java/C++ 的抽象工厂写法，只会导致类型断言泛滥、初始化逻辑散乱、测试困难。
实操建议：
- 先定义清晰的组件接口（如
Button、Dialog），而非先设计工厂接口 - 每个平台实现一个工厂函数包，比如
win.NewButton()、mac.NewButton()，返回各自平台的具体结构体 - 避免用
func NewWidget(factory Factory) Widget这种带参数工厂——Go 里传 factory 接口不如直接调用对应平台的构造函数直观 - 跨平台初始化入口统一用构建标签（
//go:build windows）或运行时runtime.GOOS分支，而不是靠工厂对象动态选择
UI 组件库必须隔离平台依赖，否则 build 失败是常态
Windows API 调用混进 macOS 构建流程？ld: framework not found CoreGraphics 这类错误根本不是代码问题，而是构建边界没划清。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 在通用组件文件里 import
"golang.org/x/sys/windows"，导致 Linux/macOS 构建失败 - 用
build constraints错误地放在函数内部（无效），或漏掉+build前的空行 - 平台专属资源（图标、字体路径）硬编码成绝对路径，如
"C:/res/close.png"
实操建议：
- 按平台拆包：
ui/win/、ui/mac/、ui/gtk/，各自实现同一组接口 - 所有构建标签写在文件顶部，格式为
//go:build windows，并紧跟package ui - 资源路径统一走
embed.FS+runtime/debug.ReadBuildInfo()判断打包环境，不拼接 OS 特定路径
组件生命周期管理别交给工厂，Go 里 defer 和 struct 字段更可靠
抽象工厂模式常被误用来“统一释放资源”，但在 Go 中，defer、Close() 方法、以及结构体内嵌 sync.Once 才是真实可靠的释放手段。工厂本身无状态，也不该承担清理职责。
容易踩的坑：
- 工厂返回的对象没有实现
io.Closer，但文档暗示“由工厂统一销毁”——结果 goroutine 泄漏、句柄未关 - 在工厂方法里启动 goroutine 监听窗口关闭事件，却没提供停止机制，导致无法测试、无法复用
- 把
*C.HWND或C.GdkWindow存在工厂全局 map 里，引发竞态和内存泄漏
实操建议：
- 每个可销毁组件实现
Close() error，调用方负责 defer 或显式调用 - 需要异步监听的组件（如消息循环），用
chan struct{}控制启停，字段内嵌，不外泄控制权 - 工厂函数只做创建，不做持有；生命周期完全交还给使用者
跨平台 UI 库性能瓶颈不在工厂模式，而在 CGO 调用频次和内存拷贝
你花半天优化工厂接口嵌套层级，但真正卡顿来自每帧调用 200 次 C.SendMessage，或反复把 Go 字符串转成 *C.char。
性能影响关键点：
- CGO 调用开销远高于纯 Go 函数，尤其在高频事件（鼠标移动、滚动）中应批量处理或节流
-
C.CString分配 C 堆内存，必须配对C.free，漏掉就内存泄漏；比用unsafe.String+uintptr(unsafe.Pointer(...))更重 - 平台原生控件树和 Go 对象树双维护，同步逻辑写错会导致界面卡死或崩溃，而非报错
实操建议：
- 用
//export暴露 C 回调函数时，确保参数全部是 C 类型，避免在 C 侧调 Go 函数传复杂结构 - 字符串传递优先用
unsafe.Slice+unsafe.String零拷贝方式（需确认目标 API 接收 const char* 且不保存指针） - 对频繁更新的属性（如按钮文本），加 dirty flag + 批量刷新，不要每次 setter 都触发 CGO 调用
抽象工厂本身不解决跨平台 UI 的核心矛盾：原生 API 差异大、生命周期模型不一致、资源归属模糊。它只是组织创建逻辑的一层薄皮，真正在意的应该是那几个 Close() 是否被调了，C.free 是否漏了，还有构建标签有没有多打一个空格。
