直接用回调函数管理异步任务状态易失控，因回调无上下文生命周期信息，可能在任务取消后仍被调用；应让context.Context参与通知守门，用原子状态机建模并严格耦合状态变更与通知。
为什么直接用回调函数管理异步任务状态容易失控
因为状态变更通知函数（比如 onSuccess、onFailure）本身不携带上下文生命周期信息，一旦任务被取消或超时，回调仍可能被调用，导致重复处理、panic 或数据竞争。Go 里常见错误是把 context.Context 仅用于取消传播，却没让它参与状态通知的守门逻辑。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有状态通知函数必须接收
context.Context参数，并在入口处检查ctx.Err() != nil，立即返回 - 避免在 goroutine 中裸调用回调——应先用
select+ctx.Done()判断是否还该执行 - 不要把回调函数存为全局变量或结构体字段长期持有；每次任务启动时动态构造带当前 ctx 的闭包
如何用 struct 封装带状态机语义的任务对象
单纯靠几个布尔字段（isRunning、isDone）无法表达“已取消但回调未执行”这类中间态。需要显式建模有限状态，且每个状态迁移必须原子化。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义枚举型状态：如
TaskStatePending、TaskStateRunning、TaskStateSucceeded、TaskStateFailed、TaskStateCancelled - 用
sync/atomic操作状态值，而非 mutex 包裹整个方法——避免在通知回调中阻塞其他状态更新 - 暴露
TransitionTo(newStatus TaskState)方法，内部校验迁移合法性（例如不允许从Succeeded回退到Running）
示例关键片段：
type Task struct {
state atomic.Int64
}
func (t *Task) TransitionTo(s TaskState) bool {
from := t.state.Load()
if !isValidTransition(from, int64(s)) {
return false
}
return t.state.CompareAndSwap(from, int64(s))
}
通知函数触发时机必须与状态变更严格耦合
很多 bug 来源于“先发通知，再改状态”，或者反过来。当多个 goroutine 并发调用 Done() 和 Cancel() 时，顺序错乱会导致通知被遗漏或重复。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 状态变更和通知必须在一个原子操作内完成：先
TransitionTo成功，再同步调用对应通知函数 - 通知函数本身不应修改任务状态——它是只读观察者，否则会破坏状态机封闭性
- 若需异步通知（比如发消息到 channel），应复制必要状态快照（如
err、result），而不是传指针或引用原 task 实例
context.WithCancel 配合 Done channel 的陷阱
直接监听 ctx.Done() 并在其中调用通知函数，看似简洁，但存在竞态：cancel 调用和状态写入可能不同步，导致通知看到过期状态。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖
ctx.Done()触发状态变更——它只表示“请求取消”，不代表“已取消” - 真正状态变更仍要走
TransitionTo(TaskStateCancelled)，并在该方法内派生通知 - 如果要用 channel 通知外部，推荐用
chan TaskState而非chan struct{}，让监听方能明确知道发生了什么状态变化
容易被忽略的是：状态变更和通知之间没有天然的内存屏障，atomic 写状态后，必须确保通知函数读到的是最新值——这要求所有状态字段都通过原子操作或 mutex 统一访问，不能混用。
