抽象工厂在Go中无需interface{}，靠interface+工厂函数即可实现；核心是定义产品接口（如Button、Checkbox）和工厂接口（UIFactory），由具体工厂返回满足接口的本地化结构体，从而解耦产品族并支持跨平台UI切换。
抽象工厂在 Go 里没有 interface{} 就没法玩？
不是。Go 没有类继承，但抽象工厂的核心是「封装对象创建逻辑」和「解耦产品族」，靠 interface + 工厂函数就能实现，根本不需要模拟类层级。关键在于定义清晰的产品接口，再让不同工厂返回满足同一接口但行为不同的实例。
常见错误是硬写一堆 struct{} 然后靠类型断言判断“属于哪个产品族”——这等于把工厂逻辑泄露到调用侧，违背了模式本意。
- 产品接口必须窄而稳定，比如
Button只暴露Render()，不暴露平台相关字段 - 每个具体工厂（如
WindowsFactory、MacOSFactory）只返回实现了该接口的本地化结构体 - 工厂本身不实现产品接口，它只是“生产者”，返回值才是实现者
怎么写一个可切换 UI 组件族的抽象工厂？
以跨平台 GUI 组件为例：需要同时支持 Windows 和 macOS 风格的 Button 和 Checkbox。抽象工厂要保证同一系统下组件风格一致，不能混用。
核心是两个层级的接口分离：UIFactory 定义创建能力，Button/Checkbox 定义使用能力。工厂返回的对象必须同时满足所有产品接口，才能组成“一族”。
立即学习“go语言免费学习笔记（深入）”；
type Button interface {
Render() string
}
type Checkbox interface {
Toggle() string
}
type UIFactory interface {
CreateButton() Button
CreateCheckbox() Checkbox
}
type WindowsFactory struct{}
func (w WindowsFactory) CreateButton() Button {
return &WindowsButton{}
}
func (w WindowsFactory) CreateCheckbox() Checkbox {
return &WindowsCheckbox{}
}
type WindowsButton struct{}
func (b *WindowsButton) Render() string {
return "Rendering a Windows-style button"
}
type WindowsCheckbox struct{}
func (c *WindowsCheckbox) Toggle() string {
return "Toggling Windows checkbox"
}
为什么不用 new(WindowsButton) 直接构造？
直接调用 new(WindowsButton) 或字面量初始化会把具体类型暴露给业务代码，导致后续想切到 macOS 风格时，得全局搜索替换所有 WindowsButton —— 这就是抽象工厂要解决的问题：让上层只依赖接口，不感知实现。
Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。
另一个常被忽略的点是：工厂函数应尽量无状态。如果工厂内部缓存了配置或连接池，容易引发并发问题或测试困难。推荐把差异化参数（如 theme、locale）作为工厂构造参数传入，而不是在 CreateXXX() 方法里动态判断：
- ❌ 错误：在
CreateButton()里读环境变量决定返回哪种按钮 - ✅ 正确：用
NewMacOSFactory(theme string)构造工厂，内部保存theme，各Create方法复用它
抽象工厂和简单工厂、建造者混用时要注意什么？
抽象工厂管的是「产品族」，简单工厂管的是「单个产品类型」，建造者管的是「复杂对象的逐步构建」。三者可以共存，但边界必须清晰。
例如：用抽象工厂返回一个 Dialog 接口，而这个 Dialog 内部可能用建造者模式组装多个 Button 和 Label —— 此时工厂不关心 Dialog 怎么建，只负责提供符合当前平台契约的 Dialog 实例。
最容易踩的坑是让抽象工厂承担太多职责：比如在 CreateDialog() 里又去调用 buttonBuilder.SetSize().SetColor()。这会让工厂变得臃肿且难以测试。应该把构建逻辑下沉，工厂只做“选择并组合”。
真正难的不是写出来，而是守住接口边界：一旦某个 CreateXXX() 开始返回具体类型（比如返回 *sql.DB 而不是 DBClient 接口），整个抽象就塌了一半。
