在 go 中，当一个操作涉及多个结构体时，应优先将方法绑定到语义上“主导行为”的接收者上；若无明显主导方，则选用普通函数，并结合接口设计提升可测试性与可扩展性。
在 go 中，当一个操作涉及多个结构体时，应优先将方法绑定到语义上“主导行为”的接收者上；若无明显主导方，则选用普通函数，并结合接口设计提升可测试性与可扩展性。
Go 的类型系统强调清晰的语义归属与组合能力，而非继承或泛化。面对 ProbeManager 和 ProbeWorker 两个结构体，以及需协同完成的 run 操作，三种实现方式（m.run(w)、w.run(m)、run(m, w)）虽语法合法，但其设计选择直接影响代码的可维护性、可测试性与演进弹性。
✅ 推荐原则：方法服务于语义主导方，函数服务于协作逻辑
-
若 run 的核心职责是 由管理者调度并驱动工作器执行任务（例如启动、监控、重试等生命周期管理），则 run 应作为 *ProbeManager 的方法：
func (m *ProbeManager) Run(w *ProbeWorker) error { // 启动 worker，记录日志，更新状态，触发回调等 return w.Start() }此时 ProbeManager 是行为的发起者与协调者，方法归属自然，也便于后续抽象为接口。
-
反之，若 run 本质是 工作器自身的执行逻辑，仅需临时访问管理器配置或回调能力（如上报状态），则更宜定义为 *ProbeWorker 的方法，并通过字段或构造注入依赖：
type ProbeWorker struct { manager *ProbeManager // 或更推荐：manager Manager（接口） } func (w *ProbeWorker) Run() error { // 使用 w.manager 进行状态上报或策略查询 return w.doWork() } -
当 run 是纯粹的协作函数，不天然属于任一结构体的职责（例如一次性的批量校验、跨组件桥接逻辑），或需频繁切换参与对象（如未来支持 ProbeWorkerV2、MockWorker），则应定义为包级函数：
func RunProbe(m *ProbeManager, w *ProbeWorker) error { if !m.CanSchedule(w) { return errors.New("schedule denied") } return w.Execute(m.Context()) }此类函数保持无状态、高内聚，易于单元测试，也避免了人为强加的“主从”关系。
? 关键优势：接口抽象带来的工程价值
无论选择哪种形态，尽早提取接口是 Go 最佳实践的核心。以 Manager 接口为例：
type Manager interface {
Run(w *ProbeWorker) error
CanSchedule(w *ProbeWorker) bool
}
// 实现可轻松替换
var defaultManager Manager = &ProbeManager{}
// 测试时可注入 mock
type mockManager struct{ called bool }
func (m *mockManager) Run(_ *ProbeWorker) error { m.called = true; return nil }
func (m *mockManager) CanSchedule(_ *ProbeWorker) bool { return true }接口不仅支撑依赖注入和 Mock 测试，还为以下场景提供基础：
- 插件化扩展：第三方实现 FTPManager 并注册，主流程无需修改；
- 中间件模式：loggingManager 包裹原始 Manager，自动记录耗时与错误；
- 标准库兼容：如 io.Reader/io.Writer，使自定义类型无缝接入 fmt, json, http 等生态。
⚠️ 注意事项与反模式
- ❌ 避免“为接口而接口”：若某类型仅有一个实现且无扩展计划，过早抽象反而增加认知负担。
- ❌ 避免方法接收冗余参数：func (m *ProbeManager) Run(w *ProbeWorker, cfg Config) 应考虑将 cfg 提前注入 m 或拆分为独立配置函数。
- ✅ 优先组合而非继承：用 struct{ *ProbeManager } 嵌入复用，比在子类型中重复实现更符合 Go 哲学。
- ✅ 函数命名体现意图：RunProbe 比 run 更明确；方法名首字母大写（Run）以导出，供外部调用。
综上，Go 中函数与方法的选择不是语法偏好，而是职责建模的艺术。以语义清晰性为起点，以接口可组合性为终点，让代码既易读、易测，又具备面向未来的演化能力。
