在 go 中，是否应在方法内部启动 goroutine，取决于该行为是否为类型语义的**必需组成部分**；若并发是功能正确性的前提（如监听、轮询、通道消费等），应由方法内部启动并明确文档化；否则应暴露同步接口，由调用方按需并发化。
Go 的并发模型强调“不要通过共享内存来通信，而要通过通信来共享内存”，但这一哲学并不直接规定 goroutine 的责任归属。真正决定权在于接口契约（interface contract）：该方法的行为是否天然要求异步执行才能满足其语义？
✅ 推荐做法：按语义决定 goroutine 所有权
| 场景 | 示例 | 推荐方式 | 理由 |
|---|---|---|---|
| 必须并发才可工作（如长期监听、后台轮询、消费者协程） | srv.Serve(), cli.ListenAndServe(), 自定义 Poller.Run() 持续读取传感器数据 | ✅ 方法内部启动 go t.doRun() | 若不并发，调用即阻塞或失效；用户无法“正确使用”该 API 而不加 go —— 此时隐藏 go 是降低错误率、提升可用性。 |
| 可同步/可异步皆合理（如单次计算、转换、验证） | json.Marshal(), strings.ToUpper() | ❌ 不启动 goroutine，仅提供同步方法 | 并发不是语义必需；由调用方决定是否 go f() 或 f()，更灵活、更易测试、更符合组合原则。 |
? 实际代码示例
假设你有一个轮询外部状态的服务：
type Poller struct {
url string
done chan struct{}
}
// ✅ 正确：Run 是“启动后台服务”的语义，必须并发
func (p *Poller) Run() {
go p.runLoop() // 启动 goroutine 是实现契约的一部分
}
func (p *Poller) runLoop() {
ticker := time.NewTicker(30 * time.Second)
defer ticker.Stop()
for {
select {
case <-ticker.C:
p.pollOnce()
case <-p.done:
return
}
}
}
// ✅ 同时提供显式控制接口（良好实践）
func (p *Poller) Stop() { close(p.done) }对比一个纯逻辑方法：
// ✅ 正确：Transform 是纯函数式操作，无副作用、不阻塞
func (t Transformer) Transform(data []byte) ([]byte, error) {
// 同步处理
return bytes.ToUpper(data), nil
}
// 调用方可按需并发：
// go func() { out, _ := t.Transform(in) }()
// 或直接同步调用⚠️ 注意事项与最佳实践
- 文档即契约：若方法内部启动 goroutine，必须在 godoc 中清晰声明（如 Run starts a background goroutine that polls continuously），并说明生命周期管理（如何停止、是否幂等、是否可重入）。
- 避免“半隐式”并发：不要让 Run() 有时并发、有时不并发（如根据参数开关）——这破坏可预测性。
- 资源清理必须可靠：启动 goroutine 的方法通常需配套 Stop()/Close()，且应能安全多次调用（idempotent）。
- 标准库是重要参考：http.Server.ListenAndServe()、time.Ticker.C、os.Signal.Notify() 均默认启用 goroutine，因其语义本质是“提供持续服务”。
✅ 总结
你的直觉部分正确：Go 的接口本身不暴露并发细节，但类型的行为契约可能隐含并发需求。关键不是“谁写 go”，而是“不并发是否还能称为正确使用该 API？”
—— 若答案是否定的，就应在方法内启动 goroutine，并把并发作为该方法的第一公民；否则，保持同步、轻量、可组合，把并发权交还给调用方。这是 Go 惯用法（idiomatic Go）对清晰性、可靠性与可控性的共同尊重。
