continuation

// A
ajax("..", function (..) {
    // C
});
// B

//A和//B表示程序的前半部分（也就是现在的部分），而//C标识了程序的后半部分（也就是将来的部分）。前半部分立刻执行，然后是一段时间不确定的停顿。在未来的某个时刻，如果Ajax调用完成，程序就会从停下的位置继续执行后半部分。
换句话说，回调函数包裹或者说封装了程序的延续。

嵌套回调与链式回调

listen("click", function handler(evt) {
    setTimeout(function request() {
        ajax("http://some.url.1", function response(text) {
            if (text == "hello") {
                handler();
            }
            else if (text == "world") {
                request();
            }
        });
    }, 500);
});

这里我们得到了三个函数嵌套在一起构成的链，其中每个函数代表异步序列（任务，“进程”）中的一个步骤。
这种代码常常被称为回调地狱，有时也被称为毁灭金字塔。
手工硬编码（即使包含了硬编码的出错处理）回调的脆弱本性可就远没有这么优雅了。一旦你指定（也就是预选计划）了所有的可能事件和路径，代码就会变得非常复杂，以至于无法维护和更新。
这才是回调地狱的真正问题所在！嵌套和缩进基本上只是转移注意力的枝节而已。

信任问题

// A
ajax( "..", function(..){
    // C
} );
// B
//A和//B发生于现在，在JavaScript主程序的直接控制之下。而//C会延迟到将来发生，并且是在第三方的控制下——在本例中就是函数ajax(..)。从根本上来说，这种控制的转移通常不会给程序带来很多问题。
但是，请不要被这个小概率迷惑而认为这种控制切换不是什么大问题。实际上，这是回调驱动设计最严重（也是最微妙）的问题。它以这样一个思路为中心：有时候ajax(..)（也就是你交付回调continuation的第三方）不是你编写的代码，也不在你的直接控制下。多数情况下，它是某个第三方提供的工具。
我们把这称为控制反转，也就是把自己程序一部分的执行控制交给某个第三方。在你的代码和第三方工具（一组你希望有人维护的东西）之间有一份并没有明确表达的契约。
多数人都同意，至少在某种程度上我们应该在内部函数中构建一些防御性的输入参数检查，以便减少或阻止无法预料的问题。
过分信任输入：
```JavaScript
function addNumbers(x, y) {
    // +是可以重载的，通过类型转换，也可以是字符串连接
    // 所以根据传入参数的不同，这个运算并不是严格安全的
    return x + y;
}
addNumbers(21, 21); // 42
addNumbers(21, "21"); // "2121"

针对不信任输入的防御性代码：

function addNumbers(x, y) {
    // 确保输入为数字
    if (typeof x != "number" || typeof y != "number") {
        throw Error("Bad parameters");
    }
    // 如果到达这里，可以通过+安全的进行数字相加
    return x + y;
}
addNumbers(21, 21); // 42
addNumbers(21, "21"); // Error: "Bad parameters"

依旧安全但更友好一些的：

function addNumbers(x, y) {
    // 确保输入为数字
    x = Number(x);
    y = Number(y);
    // +安全进行数字相加
    return x + y;
}
addNumbers(21, 21); // 42
addNumbers(21, "21"); // 42

不管你怎么做，这种类型的检查/规范化的过程对于函数输入是很常见的，即使是对于理论上完全可以信任的代码。大体上说，这等价于那条地缘政治原则：“信任，但要核实。”
所以，据此是不是可以推断出，对于异步函数回调的组成，我们应该要做同样的事情，而不只是针对外部代码，甚至是我们知道在我们自己控制下的代码？当然应该。
但是，回调并没有为我们提供任何东西来支持这一点。我们不得不自己构建全部的机制，而且通常为每个异步回调重复这样的工作最后都成了负担。
回调最大的问题是控制反转，它会导致信任链的完全断裂。
如果你的代码中使用了回调，尤其是但也不限于使用第三方工具，而且你还没有应用某种逻辑来解决所有这些控制反转导致的信任问题，那你的代码现在已经有了bug，即使它们还没有给你造成损害。隐藏的bug也是bug。

省点回调
回调设计存在几个变体，意在解决前面讨论的一些信任问题（不是全部！）。这种试图从回调模式内部挽救它的意图是勇敢的，但却注定要失败。
举例来说，为了更优雅地处理错误，有些API设计提供了分离回调（一个用于成功通知，一个用于出错通知）：

function success(data) {
    console.log(data);
}
function failure(err) {
    console.error(err);
}
ajax("http://some.url.1", success, failure);

在这种设计下，API的出错处理函数failure()常常是可选的，如果没有提供的话，就是假定这个错误可以吞掉。
还有一种常见的回调模式叫做“error-first风格”（有时候也称为“Node”风格，因为几乎所有Node.js API都可以采用这种风格），其中回调的第一个参数保留用作错误对象（如果有的话）。如果成功的话，这个参数就会被清空/置假（后续的参数就是成功数据）。不过，如果产生了错误结果，那么第一个参数就会被置起/置真（通常就不会再传递其他结果）；

function response(err, data) {
    // 出错？
    if (err) {
        console.error(err);
    }
    // 否则认为成功
    else {
        console.log(data);
    }
}
ajax("http://some.url.1", response);

首先，这并没有像表面看上去那样真正解决主要的信任问题。这并没有涉及阻止或过滤不想要的重复调用回调的问题。现在事情更糟了，因为现在你可能同时得到成功或者失败的结果，或者都没有，并且你还是不得不编码处理所有这些情况。
另外，不要忽略这个事实：尽管这是一种你可以采用的标准模式，但是它肯定更加冗长和模式化，可复用性不高，所以你还得不厌其烦地给应用中的每个回调添加这样的代码。
那么完全不调用这个信任问题又会怎样呢？如果这是个问题的话（可能应该是个问题！），你可能需要设置一个超时来取消事件。可以构造一个工具（这里展示的只是一个“验证概念”版本）来帮助实现这一点：

function timeoutify(fn, delay) {
    var intv = setTimeout(function () {
        intv = null;
        fn(new Error("Timeout!"));
    }, delay)
        ;
    return function () {
        // 还没有超时？
        if (intv) {
            clearTimeout(intv);
            fn.apply(this, arguments);
        }
    };
}

一下是使用方式：

// 使用"error-first 风格" 回调设计
function foo(err, data) {
    if (err) {
        console.error(err);
    }
    else {
        console.log(data);
    }
}
ajax("http://some.url.1", timeoutify(foo, 500));

还有一个信任问题是调用过早。在特定应用的术语中，这可能实际上是指在某个关键人物完成之前调用回调。但是更通用地来说，对于既可能在现在（同步）也可能在将来（异步）调用你的回调的工具来说，这个问题是明显的。
这种由同步或异步行为引起的不确定性几乎总会带来极大的bug追踪难度。在某些圈子里，人们用虚构的十分疯狂的恶魔Zalgo来描述这种同步/异步噩梦。常常会有“不要放出Zalgo”这样的呼喊，而这也引出了一条非常有效的建议：永远异步调用回调，即使就在事件循环的下一轮，这样，所有回调就都是可预测的异步调用了。

function result(data) {
    console.log(a);
}
var a = 0;
ajax("..pre-cached-url..", result);
a++;

这段代码会打印出0（同步回调调用）还是1（异步回调调用）呢？这要视情况而定。
如果你不确定关注的API会不会永远异步执行怎么办呢？可以创建一个类似于这个“验证概念”版本的asyncify(..)工具。

function asyncify(fn) {
    var orig_fn = fn,
        intv = setTimeout(function () {
            intv = null;
            if (fn) fn();
        }, 0)
        ;
    fn = null;
    return function () {
        // 触发太快，在定时器intv触发指示异步转换发生之前？
        if (intv) {
            fn = orig_fn.bind.apply(
                orig_fn,
                // 把封装器的this添加到bind(..)调用的参数中，
                // 以及克里化（currying）所有传入参数
                [this].concat([].slice.call(arguments))
            );
        }
        // 已经是异步
        else {
            // 调用原来的函数
            orig_fn.apply(this, arguments);
        }
    };
}

可以像这样使用asyncify(..)：

function result(data) {
    console.log(a);
}
var a = 0;
ajax("..pre-cached-url..", asyncify(result));
a++;

不管这个Ajax请求已经在缓存中并试图对回调立即调用，还是要从网络上取得，进而在将来异步完成，这段代码总是会输出1，而不是0——result(..)只能异步调用，这意味着a++有机会在result(..)之前运行。