JavaScript 异步调用框架设计：回调传递与执行顺序保障

异步回调传递机制

首要解决的问题是如何传递回调入口。在传统的XHR调用模式中，回调函数通常作为最后一个参数传递给异步函数：

function asyncOperation(argument, callback)

当参数数量较多时，可以将参数封装在JSON对象中。这种方式类似于具名参数，允许通过参数名选择性传递，未传递的参数则使用默认值。这种从Prototype库开始流行的做法如下：

function asyncOperation(argument, options)

然而，这两种方式存在一个共同缺陷：当将同步函数改造为异步函数（或同步异步混合函数）时，必须显式修改函数签名，在末尾增加一个或多个参数。

由于在调用栈底层引入异步函数非常常见，若因此需要修改大量上层调用函数的签名，成本过高。因此，我们需要一种无需修改函数签名的解决方案。

此处参考了.NET Framework中IAsyncResult的设计思路，将异步操作相关信息集中到一个对象中，从而避免修改函数签名。假设异步函数的调用原型如下：

function asyncOperation(argument) {
operation = new Async.Operation();
setTimeout(function() { operation.yield("hello world"); }, 1000);
return operation;
} 

在这段代码中，返回了一个Operation对象，用于后续传递回调函数。同时，通过setTimeout模拟了异步返回结果，具体的返回方式由yield方法实现。

接下来，需要设计传递回调函数的方法。由于JavaScript不支持像C#那样的+=运算符重载，因此只能通过函数来传递回调：

var operation = asyncOperation(argument);
operation.addCallback(function(result) { alert(result); });

在C#中，这种设计可能存在安全隐患，因为异步操作可能在添加回调之前就已经完成。但在JavaScript中，这种写法是安全的，因为JavaScript是单线程的，紧接着asyncOperation执行的同步addCallback必然先于asyncOperation内部的异步yield执行。

执行顺序保障

调用顺序

有人可能会问，如果用户使用同步方式调用yield，此时执行顺序是否依赖于yield的实现？确实如此，但yield在框架中是一次性实现的，只需将其设计为异步即可。这样即使进行同步调用，也不会影响执行顺序：

function psudoAsyncOperation(argument) {
operation = new Async.Operation();
operation.yield("hello world");
return operation;
} 
var operation = asyncOperation(argument);
operation.addCallback(function(result) { alert(result); });

即使代码写成上述形式，我们也能确保addCallback先于yield的实际逻辑执行。

事后回调处理

事后回调

有时，框架使用者可能真的写出先yield后addCallback的代码。此时，必须保证addCallback中添加的回调函数会被立即触发。因为用户添加回调意味着期望在异步操作有结果时通知该回调，这与添加回调时异步操作是否完成无关。为此，我们添加一个用例：

function psudoAsyncOperation(argument) {
operation = new Async.Operation();
operation.yield("hello world");
return operation;
} 
var operation = asyncOperation(argument);
setTimeout(function() {
operation.addCallback(function(result) { alert(result); });
}, 1000);

至此，我们设计好了一个名为Async.Operation的异步操作对象。关于yield方法和addCallback方法的具体实现，将在下一篇文章中详细讲述。