C# 什么时候应该向异步接口方法添加CancellationToken？

我正在编写一个C#接口，它将有几个不同的实现，其中一些我无法控制。鉴于我的问题领域，所有（大多数）方法实现都将涉及某种网络通信。出于这个原因，我正在编写接口，以便所有方法都返回任务实例，并且可以异步运行。到目前为止还不错

现在我正在考虑向一些/所有接口方法添加一个

CancellationToken

参数。如果需要，可以在方法中添加

CancellationToken

• 该方法可能需要很长时间，并且
• 在某些情况下，如果操作被取消，实现可以检查令牌并防止进一步使用资源

但是，当方法实现未知时，例如编写接口时，我并不清楚标准是什么。例如，我的界面中的一些方法涉及简单的操作，在大多数情况下可能足够快，不需要取消支持，但我不能确定，因为我不能控制所有实现，而且在任何情况下，它们都将涉及网络通信，因此最终将取决于网络延迟

---

判断是否向接口方法（其实现未知）添加

CancellationToken

的经验法则/最佳实践是什么？

只需将其分开，定义一个ICancelable接口。一个类可能实现，也可能不实现，这在技术上解决了设计上的模糊性，但它使调用点复杂化了——对取消感兴趣的调用方需要在调用它之前检查是否存在可取消的方法。我想说，总是添加CancellationToken的天真标准更好——只有一个方法可以调用，实现可以选择是处理取消还是忽略该令牌。但我想看看是否有一些情况下我们完全可以不使用代币。传递

CancellationToken

几乎不花费任何成本，而改型是一个突破性的改变。唯一不好的路径是当您的方法实际上需要很长时间，但无法取消时（由于底层实现的限制）——这对调用方来说是个坏消息。在这一点上，您必须决定是将其保持在该状态，还是包含一个超时，允许操作在后台“运行”，同时仍然提前返回。所有其他场景，特别是除了进入时不检查取消的短同步方法，都不是真正的问题。扩展方法使得提供传递

CancellationToken.None的方法的重载变得微不足道，如果这是调用方的常见用例的话。只提供在接口中没有CT的方法实际上会使实现缩短执行时间，如果是这种情况，一个合理的问题是为什么该方法应该是
async
。