@reorx 多谢建议，我们会考虑，是否有必要推出其他更简洁的布局。

weibo／twitter fav 导入这里有点 tricky 想问问大家的意见。
weibo 的 fav 是私有的（在 weibo 里，只有你自己可以看到你的 fav），所以，导入之后默认私有。
twitter 的 fav 是公开的（在 twitter 里，谁都可以看到你的 fav），所以，导入之后默认公开。
貌似不大好理解，大家觉得有没有必要搞成全部都是私有的？

另外 微博／twitter 的 fav 导入是一次性的，不会重复导，但 unfav 就没有导入。

可以删，导入之后不想要，直接删了就好。

晕，漏掉了一个 0 全部都用 hash route 的页内地址伤不起。
功能说明页是 http://cliclip.com/#help/0

忘了贴 API 的文档地址： http://github.com/cliclip/htm/wiki/API-Document

aws 的 api 基本都是 build 在 http restful 的接口之上，so，这个早该出了。

debian，build from source 前一阵子还是 0.6.x 有很多 native 依赖的 module 伤不起呀。

嵌套层次太多确实难看。要追求漂亮，但不能以失去灵活性为代价。

@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 什么的。不过，思考一下倒也有益。

@linlinqi

谢谢重构，两个感觉不太适应的地方：

1. 10 行变成 23 行 ，没感觉在哪里变得更清晰了呢？
2. 从 node 的 callback(e,r) 风格转变为 resolve -> done reject -> fail 风格。

另外，如果再加一层回调呢，会变成什么样子？在实际应用中有个 5,6 层的回调不稀奇呀。

那个层次还需要再包装 resolve 和 reject 还是可以“重用” promise 又或者怎样？各个层次的异常如果要有不同的处理代码，要怎么表达呢？是：
fun1().done().fail().fun2().done().fail()
还是：
fun().done( fun2().done().fail() ).fail()
又或者还是怎样？

之前的尝试，进行到这里就退回去了（感觉没啥区别呀，而且还要分别包装 e 和 r ），没准我是那个关节没相通？

@altrixe
http://www.v2ex.com/t/53465
这贴不是说通过 flash cookie 唯一识别的么？
mac 在 http 层是不可见的东西。

@linlinqi 借机与楼上探讨。

n 层嵌套确实很难看，但我很怀疑 promise 或者 async 这类的解决方案是否真的有效。我也曾经尝试过一些 module ——感觉对代码表达的限制很大。这类东西基本都是语法糖，而且是 for control flow 的语法糖，但 control flow 其实是一段程序的精髓，是很灵活的东西，对于这个东西的抽象常常让人产生“还不如退回去的感想”。

举例说明

function some_fun(req,res,next){
－－redis.incr('next_id', function(e,r){
－－－－if(e) return next(e);
－－－－var object = {id:r, now:Date.now()};
－－－－redis.set('key', object, function(e,r){
－－－－－－if(e) return next(e);
－－－－－－res.send([1,'ok']);
－－－－}
－－}
}

贴代码没有缩进，就用－符号代替 space 了。

通常来说，似乎可以用 serial 来理解这里的两层嵌套，但，如果考虑错误处理，问题就很复杂了。比如，if(e)return next(e); 这一句 return 则可以避免内层的 redis 语句执行，是有性能意义的代码。这里的处理是极度简化之后的情况，实际情况比这可能要复杂很多。

我要表达的意思是，如果以通用的 promise 库来做 serial 之类的流程抽象，似乎无法准确的表达这里的精微之处。

@linlinqi 对此如何取舍？

>> 初次用 expressjs 写了点小东西，窃以为变量作用域名是node.js（或者应该是javascript） ugly 的一个地方。

用了很长时间的 node.js 了，真没觉得。

>> 基本每一个模块需要占用一个全局变量，

类似

var m = require('./my_module');

你可以在 node 命令行里 require 你自己的代码，然后输入 m. 按 tab 试试看。全局的可以直接按 tab 看到，或者 global. tab 查看得到。这会让你对 exports 有个感性认识。你需要了解的是 node.js 的 module 机制。参考下面的代码， module 的概念与之类似：

(funciton(){ var a = 1; .... return {x:a}; })();

这个叫啥来着，立即执行的匿名函数？闭包？反正就是这个东西了。

你的 module 对外可见的，只是你 exports.fun = xxx 的部分，其余的一律不可见（我认为，这种机制比起 public private 什么的，至少是一样的强大）。全局变量的问题，基本不用担心。

>> 而且由于回调函数里可能需要使用父级函数的局部变量，所以回调函数嵌套几层之后，感觉使用每一个变量要非常谨慎，每一个变量都是一个炸弹。

...
function some_fun(req,res,next){
redis.incr('next_id', function(e,r){
if(e) return next(e);
redis.set('key', object, function(e,r){
if(e) return next(e);
res.send([1,'ok']);
}
}
}
...

类似这样的回调层次和作用域(不同层次都有 e 和 r 存在，这里，因为有 var shadow 机制，你可以很放心地取相同的名字)，没什么可担心的。

回调使用外层的变量，这是 javascript 提供的语法机制，但如果回调里很大量地在使用外层变量，那就有可能是 bad smell 了，这很微妙，但不复杂，这种情况一般都可以很简单地重构为传参的形式。

>> 请问大家是如何规避这个问题？依靠命名规范？或者是我用法是不正确？

我认为你可能是还没有“习惯”。

btw. 个人建议慎用 coffee script 既然 plain javascript 能解决所有的问题，那就没有必要引入实质上是同一种语言（coffe script IS javascript）的另外一套语法。有个老外写过一篇，处处不记得了，转载在这里 http://cliclip.com/#clip/7/521 。

赞一下。

不过我觉得 express 的文档本身还应该再多包括点更多的东西，比如 connect 的概念什么的。否则对初学者还是太不友好了。

牛叉，谈得好透彻。

楼主加油。TB 很难治，耐药的或许更难，不过也有治好的，不要放弃希望。
我的一个同事，治了半年，已经回来上班了。
你治好回北京，我请你吃饭。

“山寨小波”的《我爱问连岳》