楼主还是先说一下你的初心是什么吧。譬如你就想打造一个轻量级的框架，我们吐槽你功能不够多岂不是鸡同鸭讲？浪费我的时间也浪费你的时间，还让大家显得生分，这就很不好。

蟑螂屋挺好使的，第一次投放里面爬满，第二次投放基本就没有了。楼主没效果是不是没有放诱饵？诱饵包要拆开把饵料倒在中间的。

纠结个啥？预期利率降低的，选 LPR，预期利率上涨的，选固定。

算法问原理和实现思路就行了，写代码就过了。手写代码没法看，机写跑不起来多尴尬。

@harde 1 万行数据全读到内存，IO 压力不要考虑的吗？

这不刚好做个 3 节点集群么？先做好 3 个配置文件，然后起 3 个 docker 容器把配置分别挂进去就好了。

剩下 32G 还可以开个虚拟机搞一堆的服务呢。

你把项目配置文件的 Eureka 地址配成测试环境不就行了吗？当然，前提是你的电脑和测试环境的网络要能够相互访问。

除了「只有一个相同类型方法的情况下，Byxx 不用写」这个点外，其他的真的没得黑。代码风格保持统一、文档严谨是对的。

客户端我都是用同样的 View 和 ViewModel，服务端接口是两个 addxxx 和 editxxx 。

@NoobX 早上刚更新完，有待观察

https://github.com/xuanbg/insight_role
https://github.com/xuanbg/insight_user
https://github.com/xuanbg/insight_tenant

结构和代码是不是都基本上都一个样？没错，就是复制一下改一改

LPR 是随着基准利率走，譬如你签约的利率是 3.5，签约的时候基准利率是 3.6，那么 LPR 就是每年的利率都是基准利率-0.1 。固定利率就是永远是 3.5 。

gitlab+nexus+jenkins

看着车，能过就过……不能过先直行到马路对面停下，然后等红灯再过路口啊。

@xuanbg 忘了说第三个，分表后 id 会重复……要死了

有条件当然不要用数据库自增。用自增有两个坏处：
1 、id 可猜测，不对，应该是可预测。简直是为别人爬数据大开方便之门。
2 、新增数据返回 id 还得额外费手脚，写主从数据时很恶心。

或者把数据解析出来批量写入也行，整个文件入库怕是不太行。