Ajax cancel
假如你熟悉 xhr，会知道 Ajax 其实可以前端主动取消，使用的是 XMLHttpRequest.abort()。当然现在也不是刀耕火种的时代，除了面试，可能基本不会手写 xhr，在无人不知的 axios 中有两种取消方法：
首先是老式 cancelToken：
const CancelToken = axios.CancelToken
const source = CancelToken.source()
axios
.get('/user/12345', {
cancelToken: source.token,
})
.catch(function (thrown) {
if (axios.isCancel(thrown)) {
console.log('Request canceled', thrown.message)
} else {
// handle error
}
})
axios.post(
'/user/12345',
{
name: 'new name',
},
{
cancelToken: source.token,
}
)
// cancel the request (the message parameter is optional)
source.cancel('Operation canceled by the user.')然后是新玩意（其实也不新）AbortController：
const controller = new AbortController()
axios
.get('/foo/bar', {
signal: controller.signal,
})
.then(function (response) {
//...
})
// cancel the request
controller.abort()cancelToken 和 signal 传到 axios 之后，都会以某种机制调用 XMLHttpRequest.abort()。
onCanceled = (cancel) => {
if (!request) {
return
}
reject(
!cancel || cancel.type ? new CanceledError(null, config, request) : cancel
)
request.abort()
request = null
}
config.cancelToken && config.cancelToken.subscribe(onCanceled)
if (config.signal) {
config.signal.aborted
? onCanceled()
: config.signal.addEventListener('abort', onCanceled)
}cancelToken 是利用发布订阅模式通知 axios 取消请求，虽然这部分是 axios 自己实现的，但是源自于一个 tc39 提案 cancelable promises proposal，不过这个提案被废弃了。
而 AbortController 是已经可以在浏览器使用的接口，顾名思义，这就是一个专门用于中止行为的控制器。mdn 的举例用的也是 Ajax 请求，不过是至潮至 in 的 fetch，从中可见 axios 跟 fetch 的实践是一致的：
function fetchVideo() {
controller = new AbortController() // 新建一个 controller
const signal = controller.signal
fetch(url, { signal }) // 在 fetch 方法传入 signal
.then(function (response) {
console.log('Download complete', response)
})
.catch(function (e) {
console.log('Download error: ' + e.message)
})
}
abortBtn.addEventListener('click', function () {
if (controller) controller.abort() // 调用 controller.abort 取消 fetch
console.log('Download aborted')
})AbortController 的其他用途
当然 AbortController 不只有中止 Ajax 一个功能，通过查看 dom 规范文档还能看到两个使用示例：
一个比较实用的例子是用 AbortController 取消事件监听：
dictionary AddEventListenerOptions : EventListenerOptions {
boolean passive = false;
boolean once = false;
AbortSignal signal;
};通过向 AddEventListener 传入 signal，运行 abort() 即可取消事件监听，这个方法对匿名回调函数尤其有用。
另一个例子是用于中止 promise。这是一个比较简洁且自文档的方法……不过其实实现这个功能也不是非要 AbortController 才能做到，只要想办法拿到 promise 的 reject 就好了。我觉得这个例子的重点偏向于学会使用 signal 的 onabort：
const controller = new AbortController();
const signal = controller.signal;
startSpinner();
doAmazingness({ ..., signal })
.then(result => ...)
.catch(err => {
if (err.name == 'AbortError') return;
showUserErrorMessage();
})
.then(() => stopSpinner());
// …
controller.abort();
function doAmazingness({signal}) {
return new Promise((resolve, reject) => {
signal.throwIfAborted();
// Begin doing amazingness, and call resolve(result) when done.
// But also, watch for signals:
signal.addEventListener('abort', () => {
// Stop doing amazingness, and:
reject(signal.reason);
});
});
}总之，signal 就是个简易发信器，而且功能偏向于取消某操作。如果在某种情况下不想自己实现一个 pubsub 对象的话，用这个就完事了。
AbortController 的介绍就到此为止吧，不知道大家有没有逐渐忘记标题……最后是想讨论一下，取消 Ajax 到底有没有用？
取消还是不取消，这是个问题
事实上，这个 Ajax 取消只是前端自说自话，后端并不知道要中止，发过去的请求还是要执行的，后端没有特殊处理的话 10s 的请求你取消了后端也仍然在费劲地跑。
那么在一些文章中看到的“优化”，所谓“取消请求，只保留最后一个”是否真的有意义呢？
分情况讨论，对于 POST 等修改数据的请求，每次发送即使返回慢，服务器也已经在处理了，取消上一个 POST 再重复发一个无疑是弱智行为。
对于 GET，且仅针对某些极限操作，或许有一点效果，例如：获取一个超长 table，结果没拿到，然后用户就用搜索快速返回少量数据并且渲染了，等到超长 table 真正返回就会覆盖掉搜索的数据，这个情况 cancel 是真的有效的。另外还有下载上传的取消，不过估计也很少会用到。
最后再说一个有道理但是事实上也是没什么用的好处：cancel 之后能省一个请求位置，毕竟浏览器一个域名的同时请求数量是有限制的，更多情况下，比 cancel 更常见的 timeout 更实用。嗯……除非同时排着五六个超慢请求，否则轮转还是比较快的……
个人建议是，说到底这个所谓“取消”都是极特殊情况的特殊处理，知道这回事就好了，没有必要没事就在拦截器里整个取消操作。