1. CancellationTokenSource 和 CancellationToken 是什么关系
可以理解成这样：
-
CancellationTokenSource（CTS） → “遥控器”
它是发信号的人，我们可以调用.Cancel()来通知任务：“你该停了”。 -
CancellationToken（Token） → “遥控器的接收器”
它只是一个只读的信号，任务内部只能用它来接收是否被取消，不能去取消别人。
CancellationTokenSource ----产生----> CancellationToken
2. 什么时候传 CancellationTokenSource
一般不建议跨方法传 CancellationTokenSource，因为：
- CTS 有
.Cancel()和.Dispose()方法，生命周期很容易被别人乱操作。 - 如果多个方法共享同一个 CTS，很容易出现遇到的 Dispose 冲突。
典型的例外场景：
当调用方需要在方法内部主动触发取消，才会传 CTS，比如：
public void StartSomething(CancellationTokenSource cts) {// 方法内部某个条件触发if (需要取消) {cts.Cancel();}
}
这种情况比较少见，大多数时候我们只是想发取消信号的人自己管理 CTS，不让别人动它。
3. 什么时候传 CancellationToken
99% 的异步任务传的应该是 CancellationToken 而不是 CTS，因为：
- Token 不能被
.Cancel()或.Dispose()，所以任务只能用它接收取消信号，而不会乱动。 - 调用方控制 CTS，保证线程安全，方法内部不需要担心 Dispose 冲突。
例如：
public async Task DoWorkAsync(CancellationToken token)
{while (!token.IsCancellationRequested){// 执行某些任务await Task.Delay(100, token); // 如果取消，这里会抛 TaskCanceledException}
}
调用方：
var cts = new CancellationTokenSource();
await DoWorkAsync(cts.Token); // 只传 Token
4. 总结口诀
- 要控制任务生命周期 → 自己持有
CancellationTokenSource（发信号的人） - 只需要监听取消信号 → 只传
CancellationToken（收信号的人） - 不要跨方法传 CTS，除非方法里确实需要主动
.Cancel()它（很少）