koa源码解读指南

图片发自简书App

导语：用过node的同学相信都知道koa。截止目前为止，koa目前官方版本最新是2.7.0。本文意在深入分析koa内部原理
本文将按照以下顺序讲解koa，通过初读到精读的方式，一步一步讲解koa涉及的相关知识。

通过阅读完本文，你将了解以下内容：
----- koa框架核心
----- 类继承在koa中的应用
----- co的实现原理，是如何将generator转为async函数的
----- 洋葱模型中间件实现原理
----- koa的统一错误处理机制
----- 委托模式在koa中的应用

一、koa是什么
koa是一个精简的node框架，它主要做了以下事情：
1.基于node原生req和res为request和response对象赋能，并基于它们封装成一个context对象。
2.基于async/await（generator）的中间件洋葱模型机制。
koa1和koa2在源码上的区别主要是于对异步中间件的支持方式的不同。
koa1是使用generator、yield的模式。
koa2使用的是async/await+Promise的模式。
下文主要是针对koa2版本源码上的讲解。

二、初读koa源码
如果你看了koa的源码，会发现koa源码其实很简单，共4个文件。
── lib
├── application.js
├── context.js
├── request.js
└── response.js

这4个文件其实也对应了koa的4个对象：
── lib
├── new Koa() || ctx.app
├── ctx
├── ctx.req || ctx.request
└── ctx.res || ctx.response

下面，我们先初步了解koa的源码内容，读懂它们，可以对koa有一个初步的了解。

2.1 application.js
application.js是koa的入口（从koa文件夹下的package.json的main字段（lib/application.js）中可以得知此文件是入口文件），也是核心部分。

下面对核心代码进行了注释。

/**

  • 依赖模块，包括但不止于下面的，只列出核心需要关注的内容
    */
    const response = require('./response');
    const compose = require('koa-compose');
    const context = require('./context');
    const request = require('./request');
    const Emitter = require('events');
    const convert = require('koa-convert');

/**

  • 继承Emitter，很重要，说明Application有异步事件的处理能力
    */
    module.exports = class Application extends Emitter {
    constructor() {
    super();

    this.middleware = []; // 该数组存放所有通过use函数的引入的中间件函数
    this.subdomainOffset = 2; // 需要忽略的域名个数
    this.env = process.env.NODE_ENV || 'development';

    // 通过context.js、request.js、response.js创建对应的context、request、response。为什么用Object.create下面会讲解
    this.context = Object.create(context);
    this.request = Object.create(request);
    this.response = Object.create(response);
    }

// 创建服务器
listen(...args) {
debug('listen');
const server = http.createServer(this.callback());
//this.callback()是需要重点关注的部分，其实对应了http.createServer的参数(req, res)=> {}
return server.listen(...args);
}
/*
通过调用koa应用实例的use函数，形如：
app.use(async (ctx, next) => {
await next();
});
来加入中间件
*/
use(fn) {
if (isGeneratorFunction(fn)) {
fn = convert(fn); // 兼容koa1的generator写法，下文会讲解转换原理
}
this.middleware.push(fn); // 将传入的函数存放到middleware数组中
return this;
}
// 返回一个类似(req, res) => {}的函数，该函数会作为参数传递给上文的listen函数中的http.createServer函数，作为请求处理的函数
callback() {
// 将所有传入use的函数通过koa-compose组合一下
const fn = compose(this.middleware);

 const handleRequest = (req, res) => {
     // 基于req、res封装出更强大的ctx，下文会详细讲解
     const ctx = this.createContext(req, res);
     // 调用app实例上的handleRequest，注意区分本函数handleRequest
    return this.handleRequest(ctx, fn);
 };

 return handleRequest;

}

// 处理请求
handleRequest(ctx, fnMiddleware) {
// 省略，见下文
}

// 基于req、res封装出更强大的ctx
createContext(req, res) {
// 省略，见下文
}
};

从上面代码中，我们可以总结出application.js核心其实处理了这4个事情：
1.启动框架
2.实现洋葱模型中间件机制
3.封装高内聚的context
4.实现异步函数的统一错误处理机制

2.2 context.js

const util = require('util');
const createError = require('http-errors');
const httpAssert = require('http-assert');
const delegate = require('delegates');

const proto = module.exports = {
// 省略了一些不甚重要的函数
onerror(err) {
// 触发application实例的error事件
this.app.emit('error', err, this);
}
}

/*
在application.createContext函数中，
被创建的context对象会挂载基于request.js实现的request对象和基于response.js实现的response对象。
下面2个delegate的作用是让context对象代理request和response的部分属性和方法
*/
delegate(proto, 'response')
.method('attachment')
...
.access('status')
...
.getter('writable')
...;

delegate(proto, 'request')
.method('acceptsLanguages')
...
.access('querystring')
...
.getter('origin')
...;

从上面代码中，我们可以总结出context.js核心其实处理了这2个事情：

1.错误事件处理

2.代理response对象和request对象的部分属性和方法

2.3 request.js

module.exports = {
// 在application.js的createContext函数中，会把node原生的req作为request对象(即request.js封装的对象)的属性
// request对象会基于req封装很多便利的属性和方法
get header() {
return this.req.headers;
},

set header(val) {
this.req.headers = val;
},

// 省略了大量类似的工具属性和方法
};

request对象基于node原生req封装了一系列便利属性和方法，供处理请求时调用。
所以当你访问ctx.request.xxx的时候，实际上是在访问request对象上的赋值器（setter）和取值器（getter）。

2.2 response.js

module.exports = {
// 在application.js的createContext函数中，会把node原生的res作为response对象（即response.js封装的对象）的属性
// response对象与request对象类似，基于res封装了一系列便利的属性和方法
get body() {
return this._body;
},

 set body(val) {
      // 支持string
      if ('string' == typeof val) {
      }

      // 支持buffer
      if (Buffer.isBuffer(val)) {
      }

      //  支持stream
      if ('function' == typeof val.pipe) {
      }

      //  支持json
     this.remove('Content-Length');
     this.type = 'json';
 },

}

response对象与request对象类似，就不再赘述。
值得注意的是，返回的body支持Buffer、Stream、String以及最常见的json，如上示例所示。

三、深入理解koa源码

koa实例化：

const Koa = require('koa');
const app = new Koa();

koa执行源码：
module.exports = class Application extends Emitter {
constructor() {
super();

this.proxy = false;
this.middleware = [];
this.subdomainOffset = 2;
this.env = process.env.NODE_ENV || 'development';
this.context = Object.create(context); //为什么要使用Object.create？ 见下面原因
this.request = Object.create(request);
this.response = Object.create(response);
if (util.inspect.custom) {
  this[util.inspect.custom] = this.inspect;
}

}
}

当实例化koa的时候，koa做了以下2件事：

  1. 继承Emitter，具备处理异步事件的能力。然而koa是如何处理，现在还不得而知，这里打个问号。
  2. 在创建实例过程中，有三个对象作为实例的属性被初始化，分别是context、request、response。还有我们熟悉的存放中间件的数组mddleware。这里需要注意，是使用Object.create(xxx)对this.xxx进行赋值。

Object.create(xxx)作用：
根据xxx创建一个新对象，并且将xxx的属性和方法作为新的对象的proto。

举个例子，代码在[demo02]：
const a = {
name: 'rose',
getName: function(){
return 'rose'
}
};

const b = Object.create(a);
console.log('a is ', a);
console.log('b is ', b);

a is:
{
getName: function() {},
name: "rose",
proto: Object {constructor: __defineGetter...}
...
}

可以看到，a的属性和方法已经挂载在b的原型（proto）下了。
所以，当执行完

this.context = Object.create(context);
this.request = Object.create(request);
this.response = Object.create(response);

的时候，以context为例，其实是创建一个新对象，使用context对象来提供新创建对象的proto，并且将这个对象赋值给this.context，实现了类继承的作用。为什么不直接用this.context=context呢？我的理解是，这样会导致两者指向同一片内存，而不是实现继承的目的。

3.2 启动应用及处理请求

在实例化koa之后，接下来，使用app.use传入中间件函数，

app.use(async (ctx,next) => {
await next();
});

koa对应执行源码：

use(fn) {
if (isGeneratorFunction(fn)) {
fn = convert(fn);
}
this.middleware.push(fn);
return this;
}

当我们执行app.use的时候，koa做了这2件事情：

  1. 判断是否是generator函数，如果是，使用koa-convert做转换（koa3将不再支持generator）。
  2. 所有传入use的方法，会被push到middleware中。

这里做下延伸讲解，如何将generator函数转为类async函数。
如何将generator函数转为类async函数:
koa2处于对koa1版本的兼容，中间件函数如果是generator函数的话，会使用koa-convert进行转换为“类async函数”。（不过到第三个版本，该兼容会取消）。
那么究竟是怎么转换的呢？
我们先来想想generator和async有什么区别？

唯一的区别就是async会自动执行，而generator每次都要调用next函数。
所以问题变为，如何让generator自动执行next函数？
所以问题变为，如何让generator自动执行next函数？

{
value: xxx,
done: false
}

返回这个对象后，如果能再次执行next，就可以达到自动执行的目的了。

看下面的例子：

function * gen(){
yield new Promise((resolve,reject){
//异步函数1
if（成功）{
resolve（）
}else{
reject();
}
});

yield new Promise((resolve,reject){
    //异步函数2
    if（成功）{
        resolve（）
    }else{
        reject();
    }
})

}
let g = gen();
let ret = g.next();

此时ret = { value: Promise实例; done: false}；value已经拿到了Promise对象，那就可以自己定义成功/失败的回调函数了。如：

ret.value.then(()=>{
g.next();
})

现在就大功告成啦。我们只要找到一个合适的方法让g.next()一直持续下去就可以自动执行了。

所以问题的关键在于yield的value必须是一个Promise。那么我们来看看co是如何把这些都东西都转化为Promise的：

function co(gen) {
var ctx = this; // 把上下文转换为当前调用co的对象
var args = slice.call(arguments, 1) // 获取参数

// we wrap everything in a promise to avoid promise chaining,
// 不管你的gen是什么，都先用Promise包裹起来
return new Promise(function(resolve, reject) {
// 如果gen是函数，则修改gen的this为co中的this对象并执行gen
if (typeof gen === 'function') gen = gen.apply(ctx, args);

// 因为执行了gen，所以gen现在是一个有next和value的对象，如果gen不存在、或者不是函数则直接返回gen
if (!gen || typeof gen.next !== 'function') return resolve(gen);

// 执行类似上面示例g.next()的代码
onFulfilled();


function onFulfilled(res) {
  var ret;
  try {
    ret = gen.next(res);  // 执行每一个gen.next()
  } catch (e) {
    return reject(e);
  }
  next(ret);  //把执行得到的返回值传入到next函数中，next函数是自动执行的关键
}


function onRejected(err) {
  var ret;
  try {
    ret = gen.throw(err);
  } catch (e) {
    return reject(e);
  }
  next(ret);
}

/**
 * Get the next value in the generator,
 * return a promise.
 */
function next(ret) {
  // 如果ret.done=true说明迭代已经完毕，返回最后一次迭代的value
  if (ret.done) return resolve(ret.value);

  // 无论ret.value是什么，都转换为Promise，并且把上下文指向ctx
  var value = toPromise.call(ctx, ret.value);

  // 如果value是一个Promise，则继续在then中调用onFulfilled。相当于从头开始！！
  if (value && isPromise(value)) return value.then(onFulfilled, onRejected);

  return onRejected(new TypeError('You may only yield a function, promise, generator, array, or object, '
    + 'but the following object was passed: "' + String(ret.value) + '"'));
}

});
}

请留意上面代码的注释。
从上面代码可以得到这样的结论，co的思想其实就是：
把一个generator封装在一个Promise对象中，然后再这个Promise对象中再次把它的gen.next()也封装出Promise对象，相当于这个子Promise对象完成的时候也重复调用gen.next()。当所有迭代完成时，把父Promise对象resolve掉。这就成了一个类async函数了。
以上就是如何把generator函数转为类async的内容。

好啦，我们继续回来看koa的源码。
当执行完app.use时，服务还没启动，只有当执行到app.listen(3000)时，程序才真正启动。
koa源码：

listen(...args) {
const server = http.createServer(this.callback());
return server.listen(...args);
}

这里使用了node原生http.createServer创建服务器，并把this.callback()作为参数传递进去。可以知道，this.callback()返回的一定是这种形式：(req, res) => {}。继续看下this.callback代码。

callback() {
// compose处理所有中间件函数。洋葱模型实现核心
const fn = compose(this.middleware);

// 每次请求执行函数(req, res) => {}
const handleRequest = (req, res) => {
  // 基于req和res封装ctx
  const ctx = this.createContext(req, res);
  // 调用handleRequest处理请求
  return this.handleRequest(ctx, fn);
};

return handleRequest;

}

handleRequest(ctx, fnMiddleware) {
const res = ctx.res;
res.statusCode = 404;

// 调用context.js的onerror函数
const onerror = err => ctx.onerror(err);

// 处理响应内容
const handleResponse = () => respond(ctx);

// 确保一个流在关闭、完成和报错时都会执行响应的回调函数
onFinished(res, onerror);

// 中间件执行、统一错误处理机制的关键
return fnMiddleware(ctx).then(handleResponse).catch(onerror);

}

从上面源码可以看到，有这几个细节很关键：

  1. compose(this.middleware)做了什么事情（使用了koa-compose包）。
  2. 如何实现洋葱式调用的？
  3. context是如何处理的？createContext的作用是什么？
  4. koa的统一错误处理机制是如何实现的？

下面，来进行一一讲解。

koa-compose和洋葱式调用
先看第一、二个问题。
看看koa-compose的精简源码：

module.exports = compose

function compose(middleware) {
return function (context, next) {
//略
}
}

compose函数接收middleware数组作为参数，middleware中每个对象都是async函数，返回一个以context和next作为入参的函数，我们跟源码一样，称其为fnMiddleware。
在外部调用this.handleRequest的最后一行，运行了中间件：

fnMiddleware(ctx).then(handleResponse).catch(onerror);

我们来看下fnMiddleware究竟是怎么实现的：

function compose (middleware) {

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, dispatch.bind(null, i + 1)));
} catch (err) {
return Promise.reject(err)
}
}
}
}

解释之前，我们通过一个例子来理解，假设加入了两个中间件。源码在[demo01]：

const Koa = require('koa');
const app = new Koa();

app.use(async (ctx,next) => {
console.log("1-start");
await next();
console.log("1-end");
});

app.use(async (ctx, next) => {
console.log("2-start");
await next();
console.log("2-end");
});
app.listen(3000);

我们逐步执行，

0：fnMiddleware(ctx)运行；

0：执行dispatch(0)；

0：进入dispatch函数，下图是各个参数对应的值。

image.png

从参数的值可以得知，最终会执行这段代码：

return Promise.resolve(fn(context, function next() {
return dispatch(i + 1)
}))

此时，fn就是第一个中间件，它是一个async函数，async函数会返回一个Promise对象，Promise.resolve()中若传入一个Promise对象的话，那么Promise.resolve将原封不动地返回这个Promise对象。

0：进入到第一个中间件代码内部，先执行“console.log("1-start")”

0：然后执行“await next()”，并开始等待next执行返回

1：进入到next函数后，执行的是dispatch(1)，于是老的dispatch(0)压栈，开始从头执行dispatch(1)，即把第二个中间件函数交给fn，然后开始执行，这就完成了程序的控制权从第一个中间件到第二个中间件的转移。下图是执行dispatch(1)时函数内变量的值：


image.png

1：进入到第二个中间件代码内部，先执行“console.log("2-start")”。然后执行“await next()”并等待next执行返回
2：进入next函数后，主要执行dispatch(2)，于是老的dispatch(1)压栈，从头开始执行dispatch(2)。下图是执行dispatch(2)时函数内变量的值：：


image.png

所以返回Promise.resolve()，此时第二个中间件的next函数返回了。

2：所以接下来执行“console.log("2-end")”
1：由此第二个中间件执行完成，把程序控制权交给第一个中间件。第一个中间件执行“console.log("1-end")”
0：终于完成了所有中间件的执行，如果中间没有异常，则返回Promise.resolve()，执行handleResponse回调；如有异常，则返回Promies.reject(err)，执行onerror回调。
建议用上面例子进行调试源码来理解，会更加清晰。

至此，回答了上面提到的2个问题：

  1. compose(this.middleware)做了什么事情（使用了koa-compose包）。
  2. 如何实现洋葱式调用的？

单一context原则
接下来，我们再来看第3个问题context是如何处理的？createContext的作用是什么？

context使用node原生的http监听回调函数中的req、res来进一步封装，意味着对于每一个http请求，koa都会创建一个context并共享给所有的全局中间件使用，当所有的中间件执行完后，会将所有的数据统一交给res进行返回，所以在每个中间件中我们才能取得req的数据进行处理，最后ctx再把要返回的body给res进行返回。

请记住句话：每一个请求都有唯一一个context对象，所有的关于请求和响应的东西都放在其里面。

下面来看context（即ctx）是怎么封装的：

// 单一context原则
createContext(req, res) {
const context = Object.create(this.context); // 创建一个对象，使之拥有context的原型方法，后面以此类推
const request = context.request = Object.create(this.request);
const response = context.response = Object.create(this.response);
context.app = request.app = response.app = this;
context.req = request.req = response.req = req;
context.res = request.res = response.res = res;
request.ctx = response.ctx = context;
request.response = response;
response.request = request;
context.originalUrl = request.originalUrl = req.url;
context.state = {};
return context;
}

本着一个请求一个context的原则，context必须作为一个临时对象存在，所有的东西都必须放进一个对象，因此，从上面源码可以看到，app、req、res属性就此诞生。

请留意以上代码，为什么app、req、res、ctx也存放在了request、和response对象中呢？

使它们同时共享一个app、req、res、ctx，是为了将处理职责进行转移，当用户访问时，只需要ctx就可以获取koa提供的所有数据和方法，而koa会继续将这些职责进行划分，比如request是进一步封装req的，response是进一步封装res的，这样职责得到了分散，降低了耦合度，同时共享所有资源使context具有高内聚的性质，内部元素互相能访问到。

在createContext中，还有这样一行代码：
context.state = {};
这里的state是专门负责保存单个请求状态的空对象，可以根据需要来管理内部内容。

异步函数的统一错误处理机制

接下来，我们再来看第四个问题：koa的统一错误处理机制是如何实现的？

回忆一下我们如何在koa中统一处理错误，只需要让koa实例监听onerror事件就可以了。则所有的中间件逻辑错误都会在这里被捕获并处理。如下所示：

app.on('error', err => {
log.error('server error', err)
});

这是怎么做到的呢？核心代码如下（在上面提到的application.js的handleRequest函数中）：

handleRequest(ctx, fnMiddleware) {
const res = ctx.res;
res.statusCode = 404;
// application.js也有onerror函数，但这里使用了context的onerror，
const onerror = err => ctx.onerror(err);
const handleResponse = () => respond(ctx);
onFinished(res, onerror);

// 这里是：中间件如果执行出错的话，都能执行到onerror的关键
return fnMiddleware(ctx).then(handleResponse).catch(onerror);

}

这里其实会有2个疑问：
1.出错执行的回调函数是context.js的onerror函数，为什么在app上监听onerror事件，就能处理所有中间件的错误呢？
请看下context.js的onerror：

onerror(err) {
this.app.emit('error', err, this);
}

这里的this.app是对application的引用，当context.js调用onerror时，其实是触发application实例的error事件 。该事件是基于“Application类继承自EventEmitter”这一事实。

2.如何做到集中处理所有中间件的错误？
我们再来回顾一下洋葱模型的中间件实现源码：

function compose (middleware) {
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, dispatch.bind(null, i + 1)));
  } catch (err) {
    return Promise.reject(err)
  }
}

}
}

还有外部处理：

// 这里是中间件如果执行出错的话，都能执行到onerror的关键！！！
return fnMiddleware(ctx).then(handleResponse).catch(onerror);

主要涉及这几个知识点：
1.async函数返回一个Promise对象
2.async函数内部抛出错误，会导致Promise对象变为reject状态。抛出的错误会被catch的回调函数(上面为onerror)捕获到。
3.await命令后面的Promise对象如果变为reject状态，reject的参数也可以被catch的回调函数(上面为onerror)捕获到。

这样就可以理解为什么koa能实现异步函数的统一错误处理了。

委托模式

最后讲一下koa中使用的设计模式——委托模式。

当我们在使用context对象时，往往会这样使用：
ctx.header 获取请求头
ctx.method 获取请求方法
ctx.url 获取请求url

这些对请求参数的获取都得益于context.request的许多属性都被委托在context上了
delegate(proto, 'request')
.method('acceptsLanguages')
...
.access('method')
...
.getter('URL')
.getter('header')
...;

又比如，

ctx.body 设置响应体
ctx.status 设置响应状态码
ctx.redirect() 请求重定向

这些对响应参数的设置都得益于koa中的context.response的许多方法都被委托在context对象上了：
delegate(proto, 'response')
.method('redirect')
...
.access('status')
.access('body')
...;

至于delegate的使用和源码就不展开了.

以上就是对koa源码所涉及的所有知识点的解析啦，初次看可能会有点晕，建议结合源码和例子一起多看几次，就会领会到koa框架的简洁和优雅之美所在了~

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 213,711评论 6赞 493
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 91,079评论 3赞 387
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 159,194评论 0赞 349
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 57,089评论 1赞 286
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 66,197评论 6赞 385
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 50,306评论 1赞 292
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,338评论 3赞 412
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,119评论 0赞 269
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,541评论 1赞 306
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,846评论 2赞 328
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,014评论 1赞 341
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,694评论 4赞 337
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,322评论 3赞 318
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,026评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,257评论 1赞 267
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 46,863评论 2赞 365
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 43,895评论 2赞 351