何时向Controller Action传递CancellationToken？最佳实践探讨

这两种观点没有绝对的对错，核心是看你的业务场景和优先级：

两种观点的本质 #

• 仅GET请求使用派

  核心担心的是有副作用的请求中断会破坏数据完整性。比如用户提交POST创建订单，中途取消请求，要是CancellationToken直接中断了业务逻辑，可能出现订单存进数据库但库存没扣的尴尬情况，Andrew Lock的观点就是从数据一致性的优先级出发，不想因请求中断搞出半拉子数据。

• 全请求使用派

  核心是想避免重复数据和浪费服务器资源。比如用户网络卡了重复点提交，或者请求挂那占着资源，用CancellationToken能终止无效请求，防止重复创建数据，同时释放服务器资源。

多表/多文件操作的风险 #

在多表关联操作、多文件上传这类需要原子性的场景里，直接用CancellationToken确实容易出数据不一致的问题：

• 比如做一个包含订单写入、库存扣减、日志记录的POST请求，要是订单写完了，库存还没扣的时候请求被取消，就会出现订单在但库存没少的矛盾状态。
• 多文件上传时，部分文件传完了请求才被取消，剩下的文件没传，导致文件集不完整，后续业务根本没法正常走。

实际项目里的正确用法 #

1. GET请求：一定要用
   GET是无副作用的查询，中断了也不会影响数据，反而能及时释放服务器资源，提升接口的可扩展性，没理由不用。
2. POST/PUT/DELETE请求：谨慎用，配合原子性保障
   • 如果是日志上报这类非核心、允许部分执行的操作，直接用就行，但要做好异常捕获。
   • 对于订单支付、多表更新这类需要原子性的核心业务，别直接把CancellationToken传到数据操作层：
     • 可以用CancellationToken监控客户端连接状态，要是检测到取消，标记请求无效，但让后台业务逻辑要么执行完，要么通过事务回滚。
     • 配合数据库事务（比如TransactionScope）或者分布式事务，保证多个操作要么全成要么全败，就算请求被取消，也能通过回滚保证数据一致。
     • 另外，用幂等性设计（比如给每个请求加唯一ID）来避免重复提交，比单纯靠CancellationToken靠谱得多。

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