前一段时间，一道疑似「微信」招聘的面试题出现，可能有不少读者已经了解过了。这道题乍一看挺难，但是细细分析却还算简单，我们甚至可以用多种手段解题，用不同思想来给出答案。

网上零零碎碎的有一些解答，但是缺乏全面梳理。我认为通过这道题，有必要将前端多重知识点「融会贯通」，在这里和大家分享。

本讲知识点如下：

题意分析

我们来先看看题目：

实现一个 LazyMan，按照以下方式调用时，得到相关输出：

LazyMan("Hank")
// Hi! This is Hank!
 
LazyMan("Hank").sleep(10).eat("dinner")
// Hi! This is Hank!
// 等待 10 秒..
// Wake up after 10
// Eat dinner~
 
LazyMan("Hank").eat("dinner").eat("supper")
// Hi This is Hank!
// Eat dinner~
// Eat supper~
 
LazyMan("Hank").sleepFirst(5).eat("supper")
// 等待 5 秒
// Wake up after 5
// Hi This is Hank!
// Eat supper

当面试者拿到这道题目的时候，乍看题干可能会有点慌张。其实很多面试失败是「自己吓唬自己」，在平时放松状态下写代码，也许解题不在话下。

下面我们就从接到题目开始，剖析应该如何进行分析：

• 可以把 LazyMan 理解为一个构造函数，在调用时输出参数内容
• LazyMan 支持链式调用
• 链式调用过程提供了以下几个方法：sleepFirst、eat、sleep
• 其中 eat 方法输出参数相关内容：Eat + 参数
• sleep 方法比较特殊，链式调用将暂停一定时间后继续执行，看到这里也许应该想到 setTimeout
• sleepFirst 最为特殊，这个任务或者这个方法的 优先级最高；调用 sleepFirst 之后，链式调用将暂停一定时间后继续执行。请再次观察题干，尤其是最后一个 demo，sleepFirst 的输出优先级最高，调用后先等待 5 秒输出 Wake up after 5，再输出 Hi This is Hank!

我们应该如何解这个题目呢，从拿到需求开始进行分析：

• 先从最简单的，我们可以封装一些基础方法，比如 log 输出、封装 setTimeout 等
• 因为 LazyMan 要实现一系列调用，且调用并不是顺序执行的，比如如果 sleepFirst 出现在调用链时，优先执行；同时任务并不是全部都同步执行的，因此我们应该实现一个任务队列，这个队列将调度执行各个任务
• 因此每次调用 LazyMan 或链式执行时，我们应该将相关调用方法加入到（push）-
  任务队列中，储存起来，后续统一被调度
• 在写入任务队列时，如果当前的方法为 sleepFirst，那么需要将该方法放到队列的最头处，这应该是一个 unshift 方法

这么一分析，这道题就「非常简单」了。

我们来试图解剖一下这道题目的考察点：

• 面向对象思想与设计，包括类的使用等
• 对象方法链式调用的理解和设计
• 小部分设计模式的设计
• 因为存在「重复逻辑」，考察代码的解耦和抽象能力
• 逻辑的清晰程度以及其他编程思维

常规思路解答
基于以上思路，我们给出较为常规的答案，其中代码已经加上了必要的注释：

class LazyManGenerator {
 constructor(name) {
   this.taskArray = []

   // 初始化时任务
   const task = () => {
     console.log(`Hi! This is ${name}`)
     // 执行完初始化时任务后，继续执行下一个任务
     this.next()
   }

   // 将初始化任务放入任务队列中
   this.taskArray.push(task)

   setTimeout(() => {
     this.next()
   }, 0)
 }

 next() {
     // 取出下一个任务并执行
   const task = this.taskArray.shift()
   task && task()
 }

 sleep(time) {
   this.sleepTask(time, false)
   // return this 保持链式调用
   return this
 }

 sleepFirst(time) {
   this.sleepTask(time, true)
   return this
 }

 sleepTask(time, prior) {
   const task = () => {
     setTimeout(() => {
       console.log(`Wake up after ${time}`)
       this.next()
     }, time * 1000)
   }

   if (prior) {
     this.taskArray.unshift(task)
   } else {
     this.taskArray.push(task)
   }
 }

 eat(name) {
   const task = () => {
     console.log(`Eat ${name}`)
     this.next()
   }

   this.taskArray.push(task)
   return this
 }
}

function LazyMan(name) {
 return new LazyManGenerator(name)
}

简单分析一下：

• LazyMan 方法返回一个 LazyManGenerator 构造函数的实例
• 在 LazyManGenerator constructor 当中，我们维护了 taskArray 用来存储任务，同时将初始化任务放到 taskArray 当中
• 还是在 LazyManGenerator constructor 中，将任务的逐个执行即 next 调用放在 setTimeout 中，这样就能够保证在开始执行任务时，taskArray 数组已经填满了任务
• 我们来看看 next 方法，取出 taskArray 数组中的首项，进行执行
• eat 方法将 eat task 放到 taskArray 数组中，注意 eat task 方法需要调用 this.next() 显式调用「下一个任务」；同时返回 this，完成链式调用
• sleep 和 sleepFirst 都调用了 sleepTask，不同在于第二个参数：sleepTask 第二个参数表示是否优先执行，如果 prior 为 true，则使用 unshift 将任务插到 taskArray 开头

这个解法最容易想到，也相对来说容易，主要是面向过程。关键点在于对于 setTimeout 任务队列的准确理解以及 return this 实现链式调用的方式。

事实上，sleepTask 应该作为 LazyManGenerator 类的私有属性出现，因为 ES class 暂时 private 属性没有被广泛实现，这里不再追求实现。

设计模式解答

关于这道题目的解答，网上最流行的是一种发布订阅模式的方案。相关代码出处：lazyMan。

但是其实仔细看其实现，也是上一环节中常规解法的变种。虽然说是发布订阅模式，但是其实仍然是 next 思想执行下一个任务的思路，该实现 publish 和 subscribe 方法分别是完成执行任务和注册任务逻辑。我认为这样的代码实现有一点「过度设计」之嫌，更像是往发布订阅模式上去靠，整体流程不够自然。

当然读者仍可参考，并有自己的思考，这里我不再更多分析。

再谈流程控制和队列、中间件启发

这道题目我们给出解法并不算完，更重要也更有价值的是思考、延伸。微信题目较好地考察了候选者的流程控制能力，而流程控制在前端开发者面前也非常重要。

我们看上述代码中的 next 函数，它负责找出 stack 中的下一个函数并执行：

next() {
   // 取出下一个任务并执行
   const task = this.taskArray.shift()
   task && task()
}

NodeJS 中 connect 类库，以及其他框架的中间件设计也都离不开类似思想的 next。比如生成器自动执行函数 co、redux、koa 也通过不同的实现，可以让 next 在多个函数之间执行完后面的函数再折回来执行 next，较为巧妙。我们具体来看一下。

senchalabs connect 和 express

具体场景：在 Node 环境中，有 parseBody、checkIdInDatabase 等相关中间件，他们组成了 middlewares 数组：

const middlewares = [
 function middleware1(req, res, next) {
   parseBody(req, function(err, body) {
     if (err) return next(err);
     req.body = body;
     next();
   });
 },
 function middleware2(req, res, next) {
   checkIdInDatabase(req.body.id, function(err, rows) {
     if (err) return next(err);
     res.dbResult = rows;
     next();
   });
 },
 function middleware3(req, res, next) {
   if (res.dbResult && res.dbResult.length > 0) {
     res.end('true');
   }
   else {
     res.end('false');
   }
   next();
 }
]

当一个请求打开时，我们需要链式调用各个中间件：

const requestHandler = (req, res) => {
 let i = 0

 function next(err) {
   if (err) {
     return res.end('error:', err.toString())
   }

   if (i < middlewares.length) {
     middlewares[i++](req, res, next)
   } else {
     return
   }
 }

 // 初始执行第一个中间件
 next()
}

基本思路和面试题解法一致：

• 将所有中间件（任务处理函数）储存在一个 list 中
• 循环依次调用中间件（任务处理函数）

senchalabs/connect 这个库做了很好的封装，是 express 等框架设计实现的原始模型。这里我们简单分析一下 senchalabs/connect 这个库的实现。

用法：

首先使用 createServer 方法创建 app 实例，

const app = createServer()

对应源码：

function createServer() {
 function app(req, res, next){ app.handle(req, res, next); }
 merge(app, proto);
 merge(app, EventEmitter.prototype);
 app.route = '/';
 app.stack = [];
 return app;
}

我们看 app 实例「继承」了 EventEmitter 类，实现事件发布订阅，同时 stack 数组来维护各个中间件任务。

接着使用 app.use 来添加中间件：

app.use('/api', function(req, res, next) {//...})

源码实现：

proto.use = function use(route, fn) {
 var handle = fn;
 var path = route;

 // default route to '/'
 if (typeof route !== 'string') {
   handle = route;
   path = '/';
 }

 // wrap sub-apps
 if (typeof handle.handle === 'function') {
   var server = handle;
   server.route = path;
   handle = function (req, res, next) {
     server.handle(req, res, next);
   };
 }

 // wrap vanilla http.Servers
 if (handle instanceof http.Server) {
   handle = handle.listeners('request')[0];
 }

 // strip trailing slash
 if (path[path.length - 1] === '/') {
   path = path.slice(0, -1);
 }

 // add the middleware
 debug('use %s %s', path || '/', handle.name || 'anonymous');
 this.stack.push({ route: path, handle: handle });

 return this;
};

通过 if...else 逻辑区分出三种不同的 fn 类型：

• fn 是一个普通的 function(req,res[,next]){} 函数
• fn 是一个普通的 httpServer
• fn 是一个普通的是另一个 connect 的 app 对象（sub app 特性）

对于这三种类型，分别转换为 function(req, res, next) {} 的形式，具体我们不再分析。最重要的执行过程是：

this.stack.push({ route: path, handle: handle })

以及返回：

return this

以上就完成了中间件即任务的注册，我们有：

app.stack = [function1, function2, function3, ...];

接下来看看任务的调度和执行。使用方法：

app.handle(req, res, out)

handle 源码实现：

proto.handle = function handle(req, res, out) {
 var index = 0;
 var protohost = getProtohost(req.url) || '';
 var removed = '';
 var slashAdded = false;
 var stack = this.stack;

 // final function handler
 var done = out || finalhandler(req, res, {
   env: env,
   onerror: logerror
 });

 // store the original URL
 req.originalUrl = req.originalUrl || req.url;

 function next(err) {
   // ...
 }

 next();
};

源码导读：out 参数是关于 sub app 的特性，这个特性可以暂时忽略，我们暂时不关心。handle 实现我们并不陌生，它构建 next 函数，并触发第一个 next 执行。

next 实现：

function next(err) {
   if (slashAdded) {
     req.url = req.url.substr(1);
     slashAdded = false;
   }

   if (removed.length !== 0) {
     req.url = protohost + removed + req.url.substr(protohost.length);
     removed = '';
   }

   // next callback
   var layer = stack[index++];

   // all done
   if (!layer) {
     defer(done, err);
     return;
   }

   // route data
   var path = parseUrl(req).pathname || '/';
   var route = layer.route;

   // skip this layer if the route doesn't match
   if (path.toLowerCase().substr(0, route.length) !== route.toLowerCase()) {
     return next(err);
   }

   // skip if route match does not border "/", ".", or end
   var c = path.length > route.length && path[route.length];
   if (c && c !== '/' && c !== '.') {
     return next(err);
   }

   // trim off the part of the url that matches the route
   if (route.length !== 0 && route !== '/') {
     removed = route;
     req.url = protohost + req.url.substr(protohost.length + removed.length);

     // ensure leading slash
     if (!protohost && req.url[0] !== '/') {
       req.url = '/' + req.url;
       slashAdded = true;
     }
   }

   // call the layer handle
   call(layer.handle, route, err, req, res, next);
}

源码导读：

取出下一个中间件

var layer = stack[index++]

如果当前请求路由和 handler 不匹配，则跳过：

if (path.toLowerCase().substr(0, route.length) !== route.toLowerCase()) {
 return next(err);
}

若匹配，则执行 call 函数，call 函数实现：

function call(handle, route, err, req, res, next) {
 var arity = handle.length;
 var error = err;
 var hasError = Boolean(err);

 debug('%s %s : %s', handle.name || '', route, req.originalUrl);

 try {
   if (hasError && arity === 4) {
     // error-handling middleware
     handle(err, req, res, next);
     return;
   } else if (!hasError && arity < 4) {
     // request-handling middleware
     handle(req, res, next);
     return;
   }
 } catch (e) {
   // replace the error
   error = e;
 }

 // continue
 next(error);
}

注意：我们使用了 try...catch 包裹逻辑，这是很必要的容错思维，这样第三方中间件的执行如果出错，不至于打挂我们的应用。

较为巧妙的一点是：function(err, req, res, next){} 形式为错误处理函数，function(req, res, next){} 为正常的业务逻辑处理函数。因此通过 Function.length 来判断当前 handler 是否为容错函数，来做到参数的传入。

call 函数是 next 函数的核心，它是一个执行者，并在最后的逻辑中继续执行 next 函数，完成中间件的顺序调用。

NodeJS 的框架 express，实际就是 senchalabs connect 的升级版，通过对 connect 源码的学习，我们应该更加清楚流程的调度和控制，再去看 express 就轻而易举了。

Senchalabs connect 用流程控制库的回调函数及中间件的思想来解耦回调逻辑；Koa 则是用 generator 方法解决回调问题（最新版使用 async/await）。事实上，也可以用事件、Promise 的方式实现，下一环节，我们就分析 Koa 的洋葱模型。

Koa 的洋葱模型

对 Koa 中间的洋葱模型的分析文章上不少，著名的洋葱圈图示我也不在自己画了，具体使用不再介绍，不了解的读者请先自行学习。

我想先谈一下面向切面编程（AOP），在 JavaScript 语言为例，一个简单的示例：

Function.prorotype.before = function (fn) {
 const self = this
 return function (...args) {
   console.log('')
   let res = fn.call(this)
   if (res) {
     self.apply(this, args)
   }
 }
}

Function.prototype.after = function (fn) {
 const self = this
 return function (...args) {
   let res = self.apply(this, args)
   if (res) {
     fn.call(this)
   }
 }
}

这样的代码实现，是我们能够在执行某个函数 fn 之前，先执行某段逻辑；在某个函数 fn 之后，再去执行另一段逻辑。其实是一种简单中间件流程控制的体现。不过这样的 AOP 有一个问题：无法实现异步模式。

那么如何实现 Koa 的异步中间件模式呢？即某个中间件执行到一半，交出执行权，之后再回来继续执行。我们直接看源码分析，这段源码实现了 Koa 洋葱模型中间件：

function compose(middleware) {
 return function *(next) {(
   if (!next) next = noop();

   var i = middleware.length;

   while (i--) {
     next = middleware[i].call(this, next);
     console.log('isGenerator:', (typeof next.next === 'function' 
                                      && typeof next.throw === 'function')); // true
   }

   return yield *next;
 }
}

function *noop(){}

其中，一个中间件的写法类似：

app.use(function *(next){
 var start = new Date;
 yield next;
 var ms = new Date - start;
 this.set('X-Response-Time', ms + 'ms');
});

这是一个很简单的记录 response time 的中间件，中间件跳转的信号是 yield next。

较新版本的 Koa 已经改用 async/await 实现，思路也是完全一样的，当然看上去更加优雅：

function compose (middleware) {
 if (!Array.isArray(middleware)) throw new TypeError('Middleware stack must be an array!')
 for (const fn of middleware) {
   if (typeof fn !== 'function') throw new TypeError('Middleware must be composed of functions!')
 }

 return function (context, next) {
   let index = -1
   return dispatch(0)

   function dispatch (i) {
     if (i <= index) return Promise.reject(new Error('next() called multiple times'))
     index = i
     let fn = middleware[i]
     if (i === middleware.length) {
       fn = next
     }
     if (!fn) return Promise.resolve()
     try {
       return Promise.resolve(fn(context, function next () {
         return dispatch(i + 1)
       }))
     } catch (err) {
       return Promise.reject(err)
     }
   }
 }
}

我们来重点解读一下这个版本的实现：

• compose 传入的 middleware 参数必须是数组，否则抛出错误
• middleware 数组的每一个元素必须是函数，否则抛出错误
• compose 返回一个函数，保存对 middleware 的引用
• compose 返回函数的第一个参数是 context，所有中间件的第一个参数就是传入的 context
• compose 返回函数的第二个参数是 next 函数，next 是实现洋葱模型的关键
• index 记录当前运行到第几个中间件
• 执行第一个中间件函数：return dispatch(0)
• dispatch 函数中，参数 i 如果小于等于 index，说明一个中间件中执行了多次 next，我们进行报错，由此可见一个中间件函数内部不允许多次调用 next 函数
• 取出中间件函数 fn = middleware[i]
• 如果 i === middleware.length，说明执行到了圆心，将 next 赋值给 fn
• 因为 async 需要后面是 Promise，我们包一层 Promise
• next 函数是固定的，它可以执行下一个中间件函数

function next () {
 return dispatch(i + 1)
}

如果读者不好理解，可以参考应用示例：

async function middleware1(ctx, next) {
 console.log('1')
 await next()
 console.log('2')
};

async function middleware2(ctx, next) {
 console.log('3')
 await next()
 console.log('4')
};

如果读者还是难以理解，我给出一个简版逻辑：

function compose (middleware) {
 return dispatch(0)
 function dispatch(i) {
   fn = middleware[i]
   if(!fn) return
   return fn(() => dispatch(i + 1))
 }
}

co 库不再神秘

说到流程控制，也少不了大名鼎鼎的 co 库。co 函数库是 TJ 大神基于 ES6 generator 的异步解决方案，因此这里需要读者熟练掌握 ES6 generator。目前虽然 co 库可能不再「流行」，但是了解其实现，模拟类似场景也是非常有必要的。

我们这里不解读其源码，而是实现一个类似的自动执行 generator 的方案：

const runGenerator = generatorFunc => {
 const it = generatorFunc()
 iterate(it)

 function iterate (it) {
   step()

   function step(arg, isError) {
     const {value, done} = isError ? it.throw(arg) : it.next(arg)

     let response

     if (!done) {
       if (typeof value === 'function') {
         response = value()
       } else {
         response = value  
       }

       Promise.resolve(response).then(step, err => step(err, true))
     }
   }
 }
}

代码解读：

• runGenerator 函数接受一个生成器函数 generatorFunc
• 运行 generatorFunc 得到结果，并通过 iterate 函数，迭代该生成器结果
• iterate 函数中执行 step 函数，step 函数的第一个参数 arg 是上一个 yield 右表达式的「求出的值」，即下面对应的 response
• 这里需要考虑 response 的求值过程，它通过 value 计算得来，value 是 yield 右侧的值，它有这么几种情况：
  • yield new Promise()，value 是一个 promise 实例，那么 response 就是该 Promise 实例 resolve 后的值
  • yield () => {return value}，value 是一个函数，那么 response 就是执行该函数后的返回值
  • yield value，value 是一个普通值，那么 response 就是该值
• 我们最终统一利用 Promise.resolve 的特性，对 response 进行处理，并递归（迭代）调用 step
• 同时利用 step 函数 arg 参数，赋值给上一个 yield 的左表达式值，并返回下一个 yield 右表达式的值

执行代码：

function* gen1() {
 yield console.log(1)
 yield console.log(2)
 yield console.log(3)
}

runGenerator(gen1)

或者：

function* gen2() {
 var value1 = yield Promise.resolve('promise')
 console.log(value1)

 var value2 = yield () => Promise.resolve('thunk')      
 console.log(value2)

 var value3 = yield 2
 console.log(value3)
}

runGenerator(gen2);

最后还是附上 co 的实现：

function co(gen) { // co 接受一个 generator 函数
   var ctx = this
   var args = slice.call(arguments, 1)

   return new Promise(function(resolve, reject) { // co 返回一个 Promise 对象
       if(typeof gen === 'function') gen = gen.apply(ctx, args) // gen 为 generator 函数，执行该函数
       if(!gen || typeof gen.next !== 'function') return resolve(gen) // 不是则返回并更新 Promise 状态为 resolve

       onFulfilled() // 将 generator 函数的 next 方法包装成 onFulfilled，主要是为了能够捕获抛出的异常
       /**
         * @param {Mixed} res
         * @return {Promise}
         * @api private
        */
       function onFulfilled(res) {
           var ret;
           try {
               ret = gen.next(res)
           } catch (err) {
               return reject(err)
           }
           next(ret)
       }

       /**
         * @param {Error} err
         * @return {Promise}
         * @api private
        */
       function onRejected(err) {
           var ret
           try {
               ret = gen.throw(err)
           } catch (err) {
               return reject(err)
           }
           next(ret)
       }

       /**
         * Get the next value in the generator,
        * return a promise.
        *
        * @param {Object} ret
        * @return {Promise}
        * @api private
        */
       function next(ret) {
           if(ret.done) return resolve(ret.value)
           var value = toPromise.call(ctx, ret.value) // if (isGeneratorFunction(obj) || isGenerator(obj)) return co.call(this, obj);
           if(value && isPromise(value)) return value.then(onFulfilled, onRejected)
           return onRejected(new TypeError('You may only yield a function, promise, generator, but the following object was passed: ' + String(ret.value) + '"'))
       }
   })
}

如果读者对于以上内容理解有困难，那么我建议还是从 generator 等最基本的概念切入，不必心急，慢慢反复体会。

总结

这道「著名」的「微信」面试题，绝不只是网上分析的几行代码答案那么简单，本讲我们从这道题目出发，分析了几种解决方案。更重要的是，在解决方案的基础上，我们重点剖析了 JavaScript 处理任务流程、控制触发逻辑的方方面面。也许在小型传统页面应用中，这样「相对复杂」的处理场景并不多见，但是在大型项目、富交互项目、后端 NodeJS 中非常重要，尤其是中间件思想、洋葱模型是非常典型的编程思路，希望读者能认真体会。

最后我们分析了 generator 以及 Koa 中间件实现原理，也许读者在平时基础业务开发中接触不到这些知识，但是请想一想 redux-saga 的实现、中间件的编写，其实都是这些内容运用体现。进阶即是如此，如果不掌握好这些「难啃」的知识，那么永远无法写出优秀的框架和解决方案。