嵌套层次太多确实难看。要追求漂亮，但不能以失去灵活性为代价。
@
luin 论坛氛围不错，我改写了例子，希望能把问题引向更深入。
主要的改写是引入了需要传递更多因素的情况，来表达这种灵活性在使用 control flow module 之后的丧失。
http://gist.github.com/4214679.js引入之后，感觉有两个问题。
传参自由度的问题：
第 6 行分别引用了两个外层里定义的 id 和 val 。对应在 async 写法的第 24 行，是不 work 的。要解决这个问题，需要显式地向外用 callback 传递或者引入一个 params object 来解决问题。需要传递的参数更多的话，可能更麻烦。
async 的思路是通过 callback 的参数传递给下一个 function 。各个 function 的变量作用域是并列的，也就是说，嵌套层次的扁平是以引用外层变量的能力作为代价的。
错误处理自由度的问题：
上述每一个错误都给了一个不同的错误处理，之前的例子是全都用 next(e) 来处理，所以，体现不出这种约束来。在 async 的版本里，所有的错误都汇集到 27 行来处理，要如何区分这许多种错误呢？
我也有用 async ，主要是用它抽象数据结构的相关方法，比如 map 之类，但 control flow 的因为上述的问题，就暂时还没有用。
@
linlinqi 这是否意味着需要在 callback(e,r) 的 node.js 标准风格和 deferred 风格之间做适配呢？这个适配，在 node 没有推出标准的 deferred 风格之前，似乎是没有动力去完成的。
还是那句话，要追求漂亮，但不能以失去灵活性为代价。我知道这可能有些不切实际，必然要 trade off 什么的。不过，思考一下倒也有益。