举个例子，欠钱不还，是违背礼义廉耻的。

欠人一千几百不还，这个人可能是老赖；
欠人一百万不还，这个人可能是背负房贷；
欠人 2.4 万亿不还，这个人是许家印。

而我们社会需要的最多的是第二种人。

这句话换个说法应该是这样的：好言难劝该死的鬼

infinity

看到 jeecg 忍不住进来踩一脚，我们也是领导强推，后端一直在填坑，深受其折磨。

后端配置表单，路由，上生产还得把 online 配置的 sql 找出来，真没减少多少工作量。
真正的收益者是前端，但是谁也不能保证下个版本不改需求，到时 online 满足不了又得用代码重写，后端工作量直接翻倍，而前端收益的兑现只能是在重写前离职。

学了一个东西，想方设法用上。

@ljrdxs 是的，我同意前后端是需要相互协作沟通的。
一般来说以往是后端先出一个后端爽的版本，然后根据前端意见进行修改。

现在我司的情况是后端出一个版本，前端出一个版本，相互 battle ，加大沟通成本。
但我认为实际这个场面是 leader 造成的，而且他只需要为结果（版本按时上线）负责，沟通过程前后端都受罪 leader 才不管。

@wu67 忘了说哈，我是后端。
我对前端定义字段并没有不满，更多的是对 leader 不满，交代前端定义接口后没有交代任何规范，摸石头过河。
最大的问题还是对实体理解的一致性，现在感觉就是一辆车有好几个方向盘，增加了很多沟通成本，后面还要赶开发进度，而且接口定义的字段命名最终还是要对齐数据库的。

现在诈骗这么舍得砸成本的么

本质都是不希望后代走自己的老路

接上，建议参考源码：
com.github.pagehelper.page.PageMethod#startPage
com.github.pagehelper.page.PageMethod#setLocalPage
com.github.pagehelper.PageInterceptor#intercept
com.github.pagehelper.PageHelper#afterAll

@SilentRhythm

PageHelper 是 Thread 级别的拦截器，然后线程是复用的，实际上是线程泄露导致。
同一条线程只要调用了 PageHelper.startPage()没有紧跟.doSelectPageInfo()就会导致上述这种不明所以的拦截。

建议排查整个项目的 PageHelper.startPage(pageNum, pageSize)调用，
然后改成紧跟 lambda 的写法
PageHelper.startPage(pageNum, pageSize).doSelectPageInfo(() -> 实现)

OP 是否背负了什么比较大的压力，如房贷 /家庭期望。
我个人也感觉自己有疑病症，加班晚一点就感觉透不过气要死了，直至去一趟医院后缓解。

最近也许想通了：世界本来就是荒诞的，如果我就这么死了，那也是命运对我的"安排"，我接收世界对我的"审判"。
至于其他事情，我都要死了哪还管得了这么多，不是我的错，我过好今天已经很不容易了。

不一定适合每个人，也不一定代表我真的能持续这种心态，和 op 共勉。

好问题，先收藏了

"她的软肋是她女儿"

别把自己当程序员

for (int i =0; i ＜ a; i ＝ i *a) {
return true;
}
return false;