为什么不能把 CancellationToken.None
当作默认参数？
因为
CancellationToken.None不是编译时常量，而 C# 的可选参数值必须是编译期能确定的常量（如字面量、
default(T)、
null）。所以你写不出这样的方法：
Task DoAsync(CancellationToken ct = CancellationToken.None) // ❌ 编译错误：不是常量
但下面这句完全合法：
Task DoAsync(CancellationToken ct = default(CancellationToken)) // ✅ 合法
虽然语义上
default(CancellationToken)和
CancellationToken.None表示同一个“不可取消”的空令牌，但前者是语言层面允许的兜底方案。
CancellationToken.None
和 default(CancellationToken)
真的等价吗？
是的，行为上完全一致：两者都满足
token.CanBeCanceled == false，
token.IsCancellationRequested == false，且
token == CancellationToken.None永远为
true（哪怕用
default构造）。 它们的
WaitHandle都是
null（无法用于
WaitAny等同步等待） 调用
token.ThrowIfCancellationRequested()永远不会抛异常 用
==或
.Equals()比较二者，结果恒为
true
实际开发中该选哪个？
看使用场景：
作为方法**可选参数的默认值** → 必须用default(CancellationToken)在逻辑中**显式表示“不希望支持取消”** → 推荐用
CancellationToken.None，语义更清晰（比如日志、断言、配置分支判断） 做单元测试时模拟“无取消需求” → 两者皆可，但用
CancellationToken.None更易读 和
CancellationTokenSource组合使用（如
CreateLinkedTokenSource）→ 传
CancellationToken.None是安全的，它会被静默忽略
例如：
var linked = CancellationTokenSource.CreateLinkedTokenSource(cts.Token, CancellationToken.None); // ✅ 安全，None 不影响链式行为
容易踩的坑：误以为 None
能“禁用取消”
CancellationToken.None不是“关闭取消功能”，而是“没有取消源”。它本身不能被取消，也不能触发任何回调——但它也不会阻止你把别的 token 传进去。常见误解： ❌ 认为传
CancellationToken.None就能让异步方法彻底无视所有取消请求（错：只是当前这个 token 不响应，不代表调用方没传别的 token） ❌ 在需要真正“可取消”的 API 中，用
None当默认值再偷偷换 token（错：破坏契约，调用方无法控制取消） ❌ 把
None和
default混在同一个项目里随意切换，导致代码语义割裂（比如有的地方写
ct == default，有的写
ct == CancellationToken.None，虽等价但难维护）
记住：选哪个不关键，关键是统一。建议团队约定——可选参数一律用
default(CancellationToken)，业务逻辑中强调意图时用
CancellationToken.None。
