今天同事突然反馈了一个问题，在系统列表页面根据时间检索数据时，有分页条数却没分页数据，具体表现如图下:
通过看日志，发现执行的sql，检索条件居然是null
看了一圈代码，都没觉得代码中有什么逻辑问题，通过Debug时发现在service中执行查询sql后，两个时间条件不见了！就离谱。在追踪字段set方法调用时，发现有如下代码：
public void isResetCreateTime() {
this.setCreateStartTime(null);
this.setCreateEndTime(null);
}
看到这个，突然觉得这代码不简单。果不其然，在注释掉这两行赋值的代码后，这bug没再重现了。啊，这～～
在service调用dao层方法上断点往下走，发现在Plugin中61行被PageHelper拦截执行了一些操作
继续往下走，发现在PageHelper中先组装执行了count sql，执行完统计条数后，再去处理执行mybatis中写的动态sql。
在上图第127行处理参数对象时，获取了查询对象中所有的get方法，并且把isResetCreateTime这个方法作为了一个get方法存入了pamarMap中，并且在put时，执行了get方法。如图：
其实到这，也就清楚了是PageHelper在处理参数的时候，把以is开头的函数认为是get方法并执行了。恰好在is开头的方法中又对属性进行了赋值动作。嗯，可以去提交记录中找找谁提交的，这不拉出来鞭尸更待何时！
在这，还有两个疑问并未继续探索，一是我如果不用PageHelper插件分页，这个问题是不是就不会出现了？二是PageHelper在处理count参数和动态sql为啥不一样，是历史遗留问题吗？ 命名需谨慎，且行且珍惜
