在 go 中，当一个操作涉及多个结构体时，优先将方法绑定到最核心、最稳定或最常被抽象的类型上，以支持接口定义、依赖注入和可测试性；普通函数适用于无状态、跨类型或工具性质的操作。
在 go 中，当一个操作涉及多个结构体时，优先将方法绑定到最核心、最稳定或最常被抽象的类型上，以支持接口定义、依赖注入和可测试性；普通函数适用于无状态、跨类型或工具性质的操作。
在 Go 的设计哲学中，“方法 vs 函数”并非语法偏好问题，而是架构决策的关键体现。以 ProbeManager 和 ProbeWorker 为例，三者看似等价的 run 实现方式——(m *ProbeManager).Run(w *ProbeWorker)、(w *ProbeWorker).Run(m *ProbeManager) 或独立函数 run(m, w)——实则隐含了截然不同的职责划分与扩展能力。
✅ 推荐方案：将方法定义在语义主导方（通常是 ProbeManager）上
若 ProbeWorker 是被调度、被管理的执行单元，而 ProbeManager 承担协调、生命周期控制、资源分配等高层职责，则 Run 的语义主体是管理者：
func (m *ProbeManager) Run(w *ProbeWorker) error {
// 启动 worker，注入上下文，记录日志，处理失败重试等
return w.Start(m.ctx, m.config)
}
此举天然支持接口抽象：
type Manager interface {
Run(*ProbeWorker) error
}
// 任意满足该接口的类型均可替代 *ProbeManager
type MockManager struct{ called bool }
func (m *MockManager) Run(_ *ProbeWorker) error { m.called = true; return nil }
func ProcessWithManager(mgr Manager, worker *ProbeWorker) error {
return mgr.Run(worker) // 编译期多态，无需修改调用逻辑
}
⚠️ 不推荐：将方法绑定到从属方（如 ProbeWorker）
func (w *ProbeWorker) Run(m *ProbeManager) error { ... } // ❌ 反向依赖
这会导致 ProbeWorker 被迫感知并耦合 ProbeManager 的存在，破坏单一职责原则；更严重的是，它难以被抽象为通用接口（如 Worker 接口不应强制依赖 Manager），限制了复用与测试能力。
?️ 独立函数适用场景（非首选，但有其位）
仅当操作不归属任一结构体的固有行为时，才考虑顶层函数：
- 类型转换工具：func WorkerToDTO(w *ProbeWorker) WorkerDTO
- 跨领域纯逻辑：func ValidateProbeConfig(cfg Config) error
- 初始化组合对象：func NewProbeSystem(mgr *ProbeManager, worker *ProbeWorker) *System
此时函数签名清晰表达“协作关系”，但放弃接口扩展能力，应谨慎使用。
? 关键决策 checklist
| 维度 | 方法（推荐） | 独立函数 |
|---|---|---|
| 是否需接口抽象 | ✅ 支持 interface{ Run(...); } | ❌ 无法直接参与接口实现 |
| 是否便于单元测试 | ✅ 可轻松 mock 替换 | ❌ 需重构依赖注入点 |
| 是否体现职责归属 | ✅ Manager.Run() 符合语义直觉 | ⚠️ run(m, w) 模糊主语 |
| 是否利于依赖倒置 | ✅ 可通过 var DefaultManager Manager = &ProbeManager{} 注入 | ❌ 调用方硬编码依赖 |
? 最佳实践总结：Go 中的方法不是“面向对象的语法糖”，而是构建可组合、可替换、可测试接口生态的基石。只要某个行为天然属于某类型的“能力”（capability），就应作为其方法；只有当它本质上是“两个类型的协作协议”且无明确主导方时，才退回到函数。宁可多一层清晰的接口抽象，也不要为短期便利牺牲长期可维护性。
