该用工厂模式而非直接 new 结构体，当需封装创建逻辑、支持多版本实现或构造过程复杂时；直接 new 易暴露内部细节，破坏封装性。
什么时候该用工厂模式而不是直接 new 结构体
当你需要封装对象创建逻辑、支持多版本实现（比如不同数据库驱动、不同支付网关），或者构造过程涉及复杂参数校验/依赖注入时，factory 比裸写 &MyStruct{...} 更可控。直接 new 容易导致调用方感知太多内部字段，一旦结构体加字段或改初始化逻辑，所有调用点都要动。
实操建议：
- 把
func NewXXX(...)放在独立的factory.go或xxx_factory.go文件里，和具体实现类型分开放 - 如果只是参数组合不同（比如
NewClientWithTimeout/NewClientWithRetry），优先用函数选项模式（Option函数），比多个工厂函数更易扩展 - 避免在工厂里做 I/O 或阻塞操作（如连接数据库），否则单元测试难 mock，应把可延迟初始化的部分拆到
Init()方法中
单例模式在 Go 里为什么常被误用
Go 的包级变量 + sync.Once 确实能轻松实现线程安全单例，但问题不在“怎么写”，而在“该不该用”。常见误用是把配置管理器、日志器、DB 连接池都做成全局单例，结果导致：
- 测试时无法替换依赖（比如想测 HTTP handler，却绕不开真实 DB 单例）
- 多个子系统共用一个实例，但它们对超时、重试、中间件的需求冲突
- 程序退出时资源清理顺序不可控（比如 logger 单例在 db 单例之后关闭，db 关闭日志就打不出）
更稳妥的做法是：用依赖注入（DI）传入所需实例，只在应用启动入口处创建一次，再逐层传递。框架如 fx 或手写构造函数链都能做到。真要单例，确保它无状态或状态完全隔离（如 sync.Pool）。
立即学习“go语言免费学习笔记（深入）”；
观察者模式在 Go 中更适合用 channel 还是接口回调
取决于事件频率、订阅者数量和可靠性要求。高频短生命周期事件（如 metrics 打点）用 chan Event 更轻量；低频、需保证送达或支持取消的场景（如配置变更通知），用注册/注销接口 + sync.Map 存回调函数更合适。
实操差异：
- channel 方案：发送端用
select { case ch 防止阻塞；接收端必须自己起 <a style="color:#f60; text-decoration:underline;" title="go" href="https://www.php.cn/zt/15863.html" target="_blank">go</a>routine 消费，且 channel 容量要设合理值，否则丢事件 - 回调方案：注意避免循环引用（比如 handler 持有 event bus，bus 又存 handler 指针），注册时用
weakref思路（如用uintptr+runtime.SetFinalizer）太重，通常直接靠文档约定“调用方负责注销” - 不要混合使用——同一事件源既发 channel 又调回调，会增加调试难度
为什么策略模式比 if-else 链更适合处理支付渠道路由
当新增渠道（如从支付宝、微信扩展到 PayPal、Stripe）时，if-else 会不断膨胀、分支条件耦合业务判断（金额、币种、地区）和执行逻辑，难以测试和复用。策略模式把每个渠道封装成独立 PaymentStrategy 接口实现，路由逻辑退化为查表：
var strategies = map[string]PaymentStrategy{
"alipay": &AlipayStrategy{},
"wechat": &WechatStrategy{},
"paypal": &PaypalStrategy{},
}
<p>func GetStrategy(name string) (PaymentStrategy, error) {
s, ok := strategies[name]
if !ok {
return nil, fmt.Errorf("unknown payment strategy: %s", name)
}
return s, nil
}关键点：
- 策略接口方法签名要一致（如
Pay(ctx context.Context, req *PayRequest) (*PayResponse, error)），不暴露各渠道私有字段 - 策略实例本身应是无状态的，状态（如 API token、endpoint）通过构造函数注入，而非从全局配置读
- 避免在策略内部做跨渠道的 fallback 逻辑（比如支付宝失败自动切微信），这属于上层编排职责，不是策略该管的
真正容易被忽略的是错误分类——不同渠道返回的错误码语义不同，统一包装成 PaymentError{Code: ErrInvalidAmount, Cause: originalErr} 才能让上层按业务意图处理，而不是写一堆 strings.Contains(err.Error(), "invalid amount")。
