创建CancellationToken时，使用TimeSpan.FromMilliseconds比常量值有何优势？

直接说结论：用TimeSpan.FromMilliseconds(1000)的方式，核心优势集中在可读性、类型安全和灵活性上，性能层面几乎没差别。

具体优势拆解： #

• 可读性拉满，语义一目了然
  直接传1000的话，除非盯着构造函数签名看，否则没人能立刻确定这个数值的单位是毫秒。但TimeSpan.FromMilliseconds(1000)明明白白告诉所有人：这是1000毫秒的延迟。要是换成更大的数值，比如3600000，直接传的话谁能一眼看出是1小时？但TimeSpan.FromHours(1)就清晰多了。

• 类型安全，减少单位混淆错误
  写代码时很容易犯“单位搞混”的低级错误——比如想等1秒，结果手滑传了1（实际是1毫秒）。用TimeSpan的方式必须明确调用对应的单位方法（FromMilliseconds/FromSeconds/FromMinutes等），从根源上降低这种失误的概率。

• 扩展性更强，调整更方便
  如果后续要修改延迟时间，比如从1秒改成2秒，用TimeSpan的话直接改成TimeSpan.FromSeconds(2)就行；而直接传数值的话得改成2000，还要反复确认单位有没有搞错。另外如果延迟时间是从其他逻辑里拿到的TimeSpan类型值，直接传进去就行，不用额外转成毫秒数，更省心。

代码示例对比 #

// 语义明确的TimeSpan方式
CancellationTokenSource ctsTs = new(TimeSpan.FromMilliseconds(1000));
// 依赖构造函数签名的数值方式
CancellationTokenSource ctsConst = new(1000);

关于性能 #

完全不用纠结——TimeSpan.FromMilliseconds内部只是简单把数值转换成TimeSpan结构，两种构造方式最终都会被解析为相同的延迟时长，性能差异可以忽略不计。

内容的提问来源于stack exchange，提问作者Daimonion