PageHelper在SpringBoot+MyBatis中合理且規(guī)范的使用方法

PageHelper

一. 開(kāi)發(fā)準(zhǔn)備

原創(chuàng)標(biāo)識(shí)

1. 開(kāi)發(fā)工具

2. 開(kāi)發(fā)環(huán)境

3. 開(kāi)發(fā)依賴(lài)

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
  <groupId>org.mybatis.spring.boot</groupId>
  <artifactId>mybatis-spring-boot-starter</artifactId>
  <version>2.1.3</version>
</dependency>
<dependency>
  <groupId>com.github.pagehelper</groupId>
  <artifactId>pagehelper-spring-boot-starter</artifactId>
  <version>1.3.0</version>
</dependency>

二. 技術(shù)文檔

原創(chuàng)標(biāo)識(shí)

1. 基于SpringBoot

2. 基于MyBatis

3. 集成PageHelper

三. 應(yīng)用講解

原創(chuàng)標(biāo)識(shí)

1. 基本使用

在實(shí)際項(xiàng)目運(yùn)用中崭闲,PageHelper的使用非常便利快捷都哭,僅通過(guò)PageInfo + PageHelper兩個(gè)類(lèi)劲赠,就足以完成分頁(yè)功能矩肩,然而往往這種最簡(jiǎn)單的集成使用方式,卻在很多實(shí)際應(yīng)用場(chǎng)景中愧捕,沒(méi)有得到充分的開(kāi)發(fā)利用.

接下來(lái)是我們最常見(jiàn)的使用方式:

public PageInfo<ResponseEntityDto> page(RequestParamDto param) {
    PageHelper.startPage(param.getPageNum(), param.getPageSize());
    List<ResoinseEntityDto> list = mapper.selectManySelective(param);
    PageInfo<ResponseEntityDto> pageInfo = (PageInfo<ResponseEntityDto>)list;
    return pageInfo;
} 

在某種程度上而言,上述寫(xiě)法的確是符合PageHelper的使用規(guī)范 :

在集合查詢(xún)前使用PageHelper.startPage(pageNum,pageSize),并且中間不能穿插執(zhí)行其他SQL

但是作為Developer的我們,往往只有在追求完美和極致的道路上才能夠?qū)さ猛黄坪蜋C(jī)遇;
以下是合理且規(guī)范的基本使用:

public PageInfo<ResponseEntityDto> page(RequestParamDto param) {
    return PageHelper.startPage(param.getPageNum(), param.getPageSize())
              .doSelectPageInfo(() -> list(param))
} 
public List<ResponseEntityDto> list(RequestParamDto param) {
    return mapper.selectManySelective(param);
}

FAQ

1. 為什么要重新聲明一個(gè)list函數(shù)?

答: 往往在很多實(shí)際業(yè)務(wù)應(yīng)用場(chǎng)景中, 分頁(yè)查詢(xún)是基于大數(shù)據(jù)量的表格展示需求來(lái)進(jìn)行的.
然而很多時(shí)候,譬如: 內(nèi)部服務(wù)的互相調(diào)用,OpenAPI的提供.
甚至在某些前后端分離聯(lián)調(diào)的業(yè)務(wù)場(chǎng)景中,是同樣需要一個(gè)非分頁(yè)集合查詢(xún)接口來(lái)提供服務(wù)的.
另外,暫時(shí)以上因素拋開(kāi)不談,我們可以根據(jù)上述寫(xiě)法來(lái)定義和規(guī)范某些東西
譬如: 分頁(yè)和集合查詢(xún)的分離和解耦(解耦詳情請(qǐng)看進(jìn)階使用),
分頁(yè)請(qǐng)求的請(qǐng)求和響應(yīng)與實(shí)際業(yè)務(wù)參數(shù)的分離(詳情請(qǐng)看進(jìn)階使用)等等...

2. doSelectPageInfo是什么?

答: doSelectPageInfoPageHelper.startPage()函數(shù)返回的默認(rèn)Page實(shí)例內(nèi)置的函數(shù),該函數(shù)可以用以Lambda的形式通過(guò)額外的Function來(lái)進(jìn)行查詢(xún)而不需要再進(jìn)行多余的PageInfoList轉(zhuǎn)換,而doSelectPageInfo的參數(shù)則是PageHelper內(nèi)置的Function(ISelect)接口用以達(dá)到轉(zhuǎn)換PageInfo的目的

3. 這種寫(xiě)法的代碼量看起來(lái)不少反多?

答: 正如同①中所描述的,就代碼量而言,確實(shí)沒(méi)有更進(jìn)一步的簡(jiǎn)化,但是再某些業(yè)務(wù)場(chǎng)景中,在已具有list函數(shù)接口的情況下,是一種更直觀(guān)的優(yōu)化(優(yōu)化詳情請(qǐng)看進(jìn)階使用)

原創(chuàng)標(biāo)識(shí)

2. 進(jìn)階使用

先看代碼,再談解析:

import com.github.pagehelper.PageHelper;
import com.github.pagehelper.PageInfo;

import java.util.List;

/**
 * @param <Param> 泛型request
 * @param <Result> 泛型response
 */
public interface BaseService<Param, Result> {

    /**
     * 分頁(yè)查詢(xún)
     *
     * @param param 請(qǐng)求參數(shù)DTO
     * @return 分頁(yè)集合
     */
    default PageInfo<Result> page(PageParam<Param> param) {
        return PageHelper.startPage(param).doSelectPageInfo(() -> list(param.getParam()));
    }

    /**
     * 集合查詢(xún)
     *
     * @param param 查詢(xún)參數(shù)
     * @return 查詢(xún)響應(yīng)
     */
    List<Result> list(Param param);
}

可以看到BaseService可以作為全局Service通用接口的封裝和聲明
而作為通用分頁(yè)接口page函數(shù)卻在此處利用interface特有關(guān)鍵字default 直接聲明了page函數(shù)的方法體body

import com.github.pagehelper.IPage;
import lombok.Data;
import lombok.experimental.Accessors;

@Data   // 為省略冗余代碼使用lombok 實(shí)際應(yīng)有常規(guī)Getter/Setter Construction toString等
@Accessors(chain = true) // 此lombok注解是為了實(shí)現(xiàn) Entity偽Build 譬如: entity.setX(x).setY(y)
public class PageParam<T>  implements IPage {

    //  description = "頁(yè)碼", defaultValue =  1
    private Integer pageNum = 1;

    //  description = "頁(yè)數(shù)", defaultValue = 20
    private Integer pageSize = 20;

    //  description = "排序", example = "id desc"
    private String orderBy;

    //  description = "參數(shù)"
    private T param;

    public PageParam<T> setOrderBy(String orderBy) {
        this.orderBy = orderBy; // 此處可優(yōu)化 優(yōu)化詳情且看解析
        return this;
    }
}

BaseService中我們看到了一個(gè)新的PageParam,參考了PageInfo用以包裝/聲明/分離分頁(yè)參數(shù)和業(yè)務(wù)參數(shù),且參數(shù)類(lèi)型為泛型,即支持任何數(shù)據(jù)類(lèi)型的業(yè)務(wù)參數(shù)
同時(shí)也可以看到PageParam實(shí)現(xiàn)了IPage接口,并且多了一個(gè)orderBy屬性字段

import common.base.BaseService;
import dto.req.TemplateReqDto;
import dto.resp.TemplateRespDto;

public interface TemplateService extends BaseService<TemplateReqDto, TemplateeRespDto> {
    // 同為interface接口, 業(yè)務(wù)Service只需要繼承BaseService
    // 并根據(jù)實(shí)際使用場(chǎng)景聲明請(qǐng)求參數(shù)和響應(yīng)結(jié)果的Entity實(shí)體即可
}

在實(shí)際應(yīng)用中,只需要聲明我們通用的業(yè)務(wù)查詢(xún)請(qǐng)求參數(shù)和響應(yīng)結(jié)果即可

import dto.req.TemplateReqDto;
import dto.resp.TemplateRespDto;
import service.TemplateService;
import persistence.mapper.TemplateMapper;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;

import java.util.List;

@Slf4j // 基于lombok自動(dòng)生成logger日志記錄實(shí)例
@Service    // SpringBoot中注冊(cè)Service Bean的注解
@RequiredArgsConstructor    // 基于lombok根據(jù)類(lèi)所有final屬性生成構(gòu)造函數(shù) 即可完成Spring構(gòu)造注入
public class TemplateServiceImpl implements TemplateService {

    private final TemplateMapper mapper;

    @Override
    public List<TemplateRespDto> list(TemplateReqDto param) {
        return mapper.selectManySelective(param) // 可根據(jù)實(shí)際情況將實(shí)體做轉(zhuǎn)換
    }
}

實(shí)現(xiàn)類(lèi)中也只需要重寫(xiě)list方法體,將實(shí)際業(yè)務(wù)場(chǎng)景中需要處理的業(yè)務(wù)邏輯處理和查詢(xún)方法寫(xiě)入其中,并不需要關(guān)心分頁(yè)功能

@Slf4j  // 同上
@RestController // SpringBoot中注冊(cè)Controller Bean的注解
@RequiredArgsConstructor    // 同上
public class TemplateController {

    public final TemplateService service;

    /**
     * 分頁(yè)查詢(xún)
     *
     * @param pageParam 分頁(yè)查詢(xún)參數(shù)
     * @return 分頁(yè)查詢(xún)響應(yīng)
     */
    @PostMapping(path = "page")
    public PageInfo<Result> page(@RequestBody PageParam<Param> pageParam) {
        return service.page(pageParam);
    }

    /**
     * 集合查詢(xún)
     *
     * @param listParam 集合查詢(xún)參數(shù)
     * @return 集合查詢(xún)響應(yīng)
     */
    @PostMapping(path = "list")
    public List<Result> list(@RequestBody Param listParam) {
        return service.list(listParam);
    }
}

最后編碼Controller接口時(shí),也只需要直接調(diào)用service.page即可,而請(qǐng)求參數(shù)直接用PageParam包裝,將分頁(yè)參數(shù)和業(yè)務(wù)參數(shù)分離,在前后端接口聯(lián)調(diào)中,保持這種==分離規(guī)范==,可以很大程度上的降低溝通和開(kāi)發(fā)成本

原創(chuàng)標(biāo)識(shí)

FAQ

1. BaseService作為interface,page為什么可以聲明方法體?

答: Java8中新特性之一就是為interface接口類(lèi)增加了static/default方法,即聲明方法后,其子類(lèi)或?qū)崿F(xiàn)都將默認(rèn)具有這些方法,可以直接調(diào)用
而在此處為Page方法聲明default是因?yàn)?code>page函數(shù)只關(guān)注分頁(yè)參數(shù)和分頁(yè)響應(yīng),脫離了業(yè)務(wù)場(chǎng)景,方法體大相徑庭,所以索性抽象定義出來(lái),免去了其實(shí)現(xiàn)的復(fù)雜冗余過(guò)程

2. PageParam的聲明有什么意義?實(shí)現(xiàn)IPage是為了什么?

答: PageParam是參考PageInfo編寫(xiě)的類(lèi)(不確定往后PageHelper是否會(huì)封裝此類(lèi),興許我可以提個(gè)Issue上去,也參與開(kāi)源框架的開(kāi)發(fā))
編寫(xiě)此類(lèi)的目的就是為了分離分頁(yè)和業(yè)務(wù)數(shù)據(jù),讓開(kāi)發(fā)者專(zhuān)注于業(yè)務(wù)的實(shí)現(xiàn)和開(kāi)發(fā),同時(shí)也是對(duì)分頁(yè)查詢(xún)API的一種規(guī)范,無(wú)論是請(qǐng)求還是響應(yīng)都將分頁(yè)相關(guān)的數(shù)據(jù)抽離出來(lái),單獨(dú)使用
而實(shí)現(xiàn)IPage則是因?yàn)?code>IPage作為PageHelper內(nèi)置的interface,在不了解它更多意義上的作用前,可以作為我們分頁(yè)參數(shù)聲明的一種規(guī)范,而IPage中也只聲明了三個(gè)方法,分別是pageNum/pageSize/orderByGetter方法,另外在源碼分析中,我將會(huì)提到實(shí)現(xiàn)此接口更深層的意義

3. PageParam中除了常規(guī)的pageNum/pageSize,為什么還需要一個(gè)orderBy?

答: 常規(guī)的分頁(yè)查詢(xún)中只需要pageNum/pageSize即可完成分頁(yè)的目的,但是往往伴隨著分頁(yè)查詢(xún)的還有篩選排序,而orderBy則是專(zhuān)注基于SQL的動(dòng)態(tài)傳參排序

4. orderBy如何使用?會(huì)有什么問(wèn)題嗎?

答: orderBypageNum/pageSize一樣,都是Pagehelper通過(guò)MyBatis攔截器,在query查詢(xún)中注入進(jìn)去的,所以在前端傳參時(shí),orderBy參數(shù)應(yīng)為數(shù)據(jù)庫(kù)column desc/asc這種形式,多字段排序則可以用逗號(hào)(,)拼接,譬如: columnA desc,columnB,
但是另外一方面又存在兩個(gè)問(wèn)題, 第一就是大多數(shù)數(shù)據(jù)庫(kù)表字段設(shè)計(jì)中,都會(huì)使用==蛇形case==命名,而非常規(guī)開(kāi)發(fā)中的==駝峰case==命名,所以存在一層轉(zhuǎn)換,而這種轉(zhuǎn)換可以分配給前端傳參時(shí),也可以分配給后端接參時(shí).
第二就是這樣赤裸裸的將排序字段暴露在接口中,會(huì)存在order by SQL注入的風(fēng)險(xiǎn),所以在實(shí)際使用過(guò)程中,我們需要通過(guò)某些手段去校驗(yàn)和排查orderBy的傳參是否合法,譬如用正則表達(dá)式匹配參數(shù)值只能含有order by語(yǔ)法中必要的值,例如字段名,desc or asc,不允許包含特殊字符/數(shù)據(jù)庫(kù)關(guān)鍵字等

5. pageNum/pageSize一定需要給默認(rèn)值嗎?

答: 通過(guò)閱讀PageHelper源碼,我們得知在Page查詢(xún)參數(shù)為null時(shí),它并不會(huì)賦予它們默認(rèn)值,并不進(jìn)行額外的處理,以至于導(dǎo)致分頁(yè)失敗,而給默認(rèn)值,也是為了謹(jǐn)防前后端調(diào)試接口過(guò)程中可能會(huì)出現(xiàn)的各種意外

3. 源碼分析

首先我們看PageHelper.startPage(param)過(guò)程中發(fā)生了什么 :

public static <E> Page<E> startPage(Object params) {
    Page<E> page = PageObjectUtil.getPageFromObject(params, true);
    Page<E> oldPage = getLocalPage();
    if (oldPage != null && oldPage.isOrderByOnly()) {
        page.setOrderBy(oldPage.getOrderBy());
    }
    setLocalPage(page);
    return page;
}

這是PageHelper繼承(extend)的抽象類(lèi)PageMethod中的一個(gè)靜態(tài)方法

再看代碼第一行 Page<E> page = PageObjectUtil.getPageFromObject(params, true)發(fā)生了什么:

public static <T> Page<T> getPageFromObject(Object params, boolean required) {
    if (params == null) {
        throw new PageException("無(wú)法獲取分頁(yè)查詢(xún)參數(shù)!");
    } else if (params instanceof IPage) {
        IPage pageParams = (IPage)params;
        Page page = null;
        if (pageParams.getPageNum() != null && pageParams.getPageSize() != null) {
            page = new Page(pageParams.getPageNum(), pageParams.getPageSize());
        }
        if (StringUtil.isNotEmpty(pageParams.getOrderBy())) {
            if (page != null) {
                page.setOrderBy(pageParams.getOrderBy());
            } else {
                page = new Page();
                page.setOrderBy(pageParams.getOrderBy());
                page.setOrderByOnly(true);
            }
        }
        return page;
    } else {
        ... // 此處我只截取了部分代碼片段, 以上是較為重要的一塊
    }
}

可以看到在此方法中,會(huì)先判斷params是否為null,再而通過(guò)instanceof判斷是否為IPage的子類(lèi)或?qū)崿F(xiàn)類(lèi)
如果以上兩個(gè)if/else 皆不滿(mǎn)足,則PageHelper則會(huì)在我省略貼出的代碼中通過(guò)大量的反射代碼來(lái)獲取pageNum/pageSize以及orderBy.
總所皆知,反射在Java中雖然廣泛應(yīng)用,并且作為語(yǔ)言獨(dú)有特性之一,深受廣大開(kāi)發(fā)者的喜愛(ài),但是反射在某種程度上,是需要性能成本的,甚至于現(xiàn)階段很多主流的框架和技術(shù),都在盡量減少反射的運(yùn)用,以防止框架性能過(guò)差,被市場(chǎng)淘汰.
那么到此為止,我們也終于解釋并知道了為什么PageParam要實(shí)現(xiàn)IPage接口了,在此處的代碼中可以直接通過(guò)接口獲取到分頁(yè)參數(shù),而不需要通過(guò)有損性能的反射獲取PageHelper需要的參數(shù)

繼續(xù)看startPage中的后續(xù)代碼:

public abstract class PageMethod {
    protected static final ThreadLocal<Page> LOCAL_PAGE = new ThreadLocal();
    protected static boolean DEFAULT_COUNT = true;

    public PageMethod() {
    }

    protected static void setLocalPage(Page page) {
        LOCAL_PAGE.set(page);
    }

    public static <T> Page<T> getLocalPage() {
        return (Page)LOCAL_PAGE.get();
    }
    ...
    ...
}

可以看到PageHelper繼承的抽象類(lèi)PageMethod中聲明了一個(gè)Page的線(xiàn)程本地變量,而getLocalPage()則是為了獲取當(dāng)前線(xiàn)程中的Page
而接下來(lái)if (oldPage != null && oldPage.isOrderByOnly())則是判斷是否存在舊分頁(yè)數(shù)據(jù)
此處的isOrderByOnly通過(guò)getPageFromObject()函數(shù)我們可以知道,當(dāng)只存在orderBy參數(shù)時(shí),即為true
也就是說(shuō),當(dāng)存在舊分頁(yè)數(shù)據(jù)并且舊分頁(yè)數(shù)據(jù)只有排序參數(shù)時(shí),就將舊分頁(yè)數(shù)據(jù)的排序參數(shù)列入新分頁(yè)數(shù)據(jù)的排序參數(shù)
然后將新的分頁(yè)數(shù)據(jù)page存入本地線(xiàn)程變量中
實(shí)際應(yīng)用場(chǎng)景中,這種情況還是比較少,僅排序而不分頁(yè),所以某種角度上而言,我們僅當(dāng)了解便好

原創(chuàng)標(biāo)識(shí)

接下來(lái)再看doSelectPageInfo(ISelect) 中發(fā)生了什么:

public <E> PageInfo<E> doSelectPageInfo(ISelect select) {
    select.doSelect();
    return this.toPageInfo();
}

可以看到,該方法的實(shí)現(xiàn)非常簡(jiǎn)單明了,就是通過(guò)注冊(cè)聲明ISelect接口由開(kāi)發(fā)自定義集合查詢(xún)方式并由它內(nèi)部執(zhí)行,隨后便返回PageInfo實(shí)體
前面我們有提到,PageHelper基于MyBatis攔截器達(dá)到分頁(yè)的目的,那么為什么此處的ISelect.doSelect()執(zhí)行,就可以返回PageInfo實(shí)體呢?
實(shí)際上這便是攔截器的妙用所在,在select.doSelect()執(zhí)行時(shí),會(huì)觸發(fā)PageHelper自定義的MyBatis查詢(xún)攔截器,并通過(guò)解析SQL和SQL參數(shù),根據(jù)數(shù)據(jù)庫(kù)類(lèi)型,進(jìn)行分頁(yè),譬如MySQL的limit,Oracle的Rownum等,
同時(shí)還會(huì)在我們定義的查詢(xún)SQL之前,PageHelper會(huì)重新生成一條select count(*)的SQL率先執(zhí)行,已達(dá)到它定義Page內(nèi)置分頁(yè)參數(shù)的目的

@Intercepts({@Signature(
    type = Executor.class,
    method = "query",
    args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}
), @Signature(
    type = Executor.class,
    method = "query",
    args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class}
)})
public class PageInterceptor implements Interceptor {
    private volatile Dialect dialect;
    private String countSuffix = "_COUNT";
    protected Cache<String, MappedStatement> msCountMap = null;
    private String default_dialect_class = "com.github.pagehelper.PageHelper";

    public PageInterceptor() {
    }

    public Object intercept(Invocation invocation) throws Throwable {
    ...
    ...
    }
}

以上便是PageHelper內(nèi)置的自定義MyBatis攔截器,因代碼量過(guò)多,為了保證不違反本博文文不對(duì)題的原則,此處不再做多余講解,如有需要,我可以另行寫(xiě)一篇博客單獨(dú)解釋并講解MyBatis攔截器的概念和原理,深度解析MyBatis源碼

拓展

PageHelper不僅有pageNum/pageSize/orderBy這幾個(gè)參數(shù),更還有pageSizeZero, reasonable參數(shù)等用以更進(jìn)階的分頁(yè)查詢(xún)定義,如需更深入的了解,我可以另行寫(xiě)一遍進(jìn)階==PageHelper==使用,此文只作為尋常開(kāi)發(fā)使用講解

原創(chuàng)標(biāo)識(shí)

四. 總結(jié)

PageHelper作為GitHub上現(xiàn)在近10K的開(kāi)源分頁(yè)框架,也許代碼深度和廣度不及主流市場(chǎng)框架和技術(shù),雖然在功能的實(shí)現(xiàn)和原理上,造輪子的難度不高,源碼也很清晰,但是在很大程度上解決了很多基于MyBatis的分頁(yè)技術(shù)難題,簡(jiǎn)化并提示了廣大開(kāi)發(fā)者的效率,這才是開(kāi)發(fā)者們?cè)陂_(kāi)發(fā)的路上應(yīng)該向往并為之拼搏的方向和道路.
而我們作為受益者,也不應(yīng)當(dāng)僅僅是對(duì)其進(jìn)行基本的使用,開(kāi)發(fā)之余,我們也應(yīng)該關(guān)注一些框架的拓展,對(duì)框架的底層有一定程度上的了解,并為之拓展和優(yōu)化

此處再次放上PageHelper的開(kāi)源倉(cāng)庫(kù)!

我是臣不貳, 你,認(rèn)識(shí)我了嗎?

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末奢驯,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子次绘,更是在濱河造成了極大的恐慌瘪阁,老刑警劉巖,帶你破解...
    沈念sama閱讀 211,265評(píng)論 6 490
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件邮偎,死亡現(xiàn)場(chǎng)離奇詭異管跺,居然都是意外死亡,警方通過(guò)查閱死者的電腦和手機(jī)禾进,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,078評(píng)論 2 385
  • 文/潘曉璐 我一進(jìn)店門(mén)豁跑,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái),“玉大人泻云,你說(shuō)我怎么就攤上這事艇拍。” “怎么了宠纯?”我有些...
    開(kāi)封第一講書(shū)人閱讀 156,852評(píng)論 0 347
  • 文/不壞的土叔 我叫張陵卸夕,是天一觀(guān)的道長(zhǎng)。 經(jīng)常有香客問(wèn)我征椒,道長(zhǎng)娇哆,這世上最難降的妖魔是什么? 我笑而不...
    開(kāi)封第一講書(shū)人閱讀 56,408評(píng)論 1 283
  • 正文 為了忘掉前任勃救,我火速辦了婚禮,結(jié)果婚禮上治力,老公的妹妹穿的比我還像新娘蒙秒。我一直安慰自己,他們只是感情好宵统,可當(dāng)我...
    茶點(diǎn)故事閱讀 65,445評(píng)論 5 384
  • 文/花漫 我一把揭開(kāi)白布晕讲。 她就那樣靜靜地躺著,像睡著了一般马澈。 火紅的嫁衣襯著肌膚如雪瓢省。 梳的紋絲不亂的頭發(fā)上,一...
    開(kāi)封第一講書(shū)人閱讀 49,772評(píng)論 1 290
  • 那天痊班,我揣著相機(jī)與錄音勤婚,去河邊找鬼。 笑死涤伐,一個(gè)胖子當(dāng)著我的面吹牛馒胆,可吹牛的內(nèi)容都是我干的缨称。 我是一名探鬼主播,決...
    沈念sama閱讀 38,921評(píng)論 3 406
  • 文/蒼蘭香墨 我猛地睜開(kāi)眼祝迂,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼睦尽!你這毒婦竟也來(lái)了?” 一聲冷哼從身側(cè)響起型雳,我...
    開(kāi)封第一講書(shū)人閱讀 37,688評(píng)論 0 266
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤当凡,失蹤者是張志新(化名)和其女友劉穎,沒(méi)想到半個(gè)月后纠俭,有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體沿量,經(jīng)...
    沈念sama閱讀 44,130評(píng)論 1 303
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 36,467評(píng)論 2 325
  • 正文 我和宋清朗相戀三年柑晒,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了欧瘪。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 38,617評(píng)論 1 340
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡匙赞,死狀恐怖佛掖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情涌庭,我是刑警寧澤芥被,帶...
    沈念sama閱讀 34,276評(píng)論 4 329
  • 正文 年R本政府宣布,位于F島的核電站坐榆,受9級(jí)特大地震影響拴魄,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜席镀,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,882評(píng)論 3 312
  • 文/蒙蒙 一匹中、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧豪诲,春花似錦顶捷、人聲如沸。這莊子的主人今日做“春日...
    開(kāi)封第一講書(shū)人閱讀 30,740評(píng)論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至交播,卻和暖如春重虑,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背秦士。 一陣腳步聲響...
    開(kāi)封第一講書(shū)人閱讀 31,967評(píng)論 1 265
  • 我被黑心中介騙來(lái)泰國(guó)打工缺厉, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 46,315評(píng)論 2 360
  • 正文 我出身青樓芽死,卻偏偏與公主長(zhǎng)得像乏梁,于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子关贵,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 43,486評(píng)論 2 348