Go中抽象工厂易成“假抽象”因缺乏继承约束，interface{}滥用迫使类型断言；应返回明确接口如Button而非interface{}，用构建标签+init注册平台工厂，避免运行时检测与map[string]func() interface{}。
为什么 Go 语言里抽象工厂模式容易写成“假抽象”
因为 Go 没有类继承和接口实现的强制约束，interface{} 或空接口滥用、工厂返回值类型太宽泛，会导致调用方不得不做类型断言甚至 switch v := obj.(type)，这已经破坏了抽象工厂“解耦具体类型”的初衷。
真正有效的做法是：让工厂方法返回明确的、业务语义清晰的接口（比如 Button、TextBox），而不是 interface{} 或 any；所有具体组件必须实现这些接口，且工厂本身不暴露构造细节。
- 避免在工厂函数里直接 new 具体结构体后转成
interface{}—— 这会让使用者被迫 type assert - 工厂方法签名应为
func() Button而非func() interface{} - 跨平台场景下，不同 OS 的组件（如
WinButton、MacButton）必须共用同一组方法签名，否则接口无法统一
如何组织跨平台 UI 组件的工厂接口与实现
关键不是“怎么定义工厂”，而是“怎么让 Windows 和 macOS 的 Button 行为差异被封装住，同时保持调用侧代码完全不变”。这就要求：工厂接口定义在顶层包（如 ui），具体实现放在子包（如 ui/win、ui/mac），而构建逻辑由构建标签或初始化时注册决定。
推荐用构建标签 + 全局变量注册的方式，比依赖注入更轻量、更符合 Go 常见实践：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义
type Button interface { Render() string }在ui包中 -
ui/win/button.go实现WinButton并满足Button接口 - 在
ui/win/init.go中用//go:build windows标签注册：func init() { ui.RegisterButtonFactory(windowsButtonFactory) } - 主程序只调用
ui.NewButton()，内部根据构建环境自动选工厂
常见错误：用 map[string]func() interface{} 模拟工厂
这种写法看似灵活，实则埋雷。典型错误现象是：运行时报 panic: interface conversion: interface {} is *win.WinButton, not ui.Button。
根本原因是：不同包下的同名结构体即使字段一致、方法一致，也不属于同一类型；而 interface{} 是类型擦除后的容器，再 cast 回目标接口会失败，除非原始值就是那个接口类型。
- 不要用
map[string]func() interface{}存工厂函数 - 不要在工厂里返回
interface{}再强转——应该直接返回Button - 如果非要动态选择（比如插件化），用
func() Button类型的 map，键是平台名，值是已适配好类型的工厂函数
构建标签 vs. 运行时检测：哪个更适合跨平台 UI？
运行时检测（如 runtime.GOOS == "windows"）看似直观，但在 CGO 依赖或平台专属 API 场景下极易出错：比如 macOS 上编译却链接了 Windows DLL，或者 iOS 构建时误含了桌面端代码。
构建标签才是 Go 官方推荐的跨平台隔离手段，它在编译期就剔除无关代码，保证二进制纯净。
- 用
//go:build darwin+//go:build !ios组合控制桌面端 macOS - 每个平台专用包都加对应构建标签，并在 init 函数中注册工厂
- 主包不 import 任何平台专用包，只依赖
ui抽象层 - CI 打包时用
GOOS=windows go build即可生成纯 Windows 二进制，无残留逻辑
最易被忽略的一点：工厂注册顺序没有保障，多个 init 函数可能冲突。务必确保只有一个地方调用 RegisterXXXFactory，且注册前检查是否已被设置。
