还有个更简单的更新会话列表的方法，就是会话状态发生变化的时候，直接丢弃整个列表数据重新加载第 0 页就好了，至于第 0 页后面的数据，自己去上拉更新。

@xuanbg 是上拉不是下拉……

@awanganddong 微信这个就是我说的分页啊，你下拉 3 次加载了第三页，找到了张三，然后你点击张三进入会话，那么张三这个会话是不是就应该提上去到第 0 页的第一条。所以刷新第 0 页，张三就会出现在会话列表的最上面。当然，在第三页你应该把张三的会话删除掉。

@awanganddong 事实上，对于会话较多的处理办法，还是分页。但这个分页不是常见的列表的那种分页，而是魔改的分页。常见的分页是从第 1 页开始，每次取 10-20 行。这种肯定是不行的了，但我们可以增加第 0 页，并定义一个较大的容量，譬如 100 行。然后自动刷新第 0 页即可。你要下拉，那就正常在 100 行之后分页加载。假设你在第 3 页找到了会话，那这个会话就会被提到最上面，你刷新第 0 页，你的会话就出现在最上面了。完美！

通用的做法就是：不分页！你看 qq 、微信、钉钉，哪个会话列表是分页的？

你一定要分页，那就接受分页带来的问题：只能刷新当前页。

@GeruzoniAnsasu 归根结底，就是谁是 root 的问题。因为操作系统本身就是 root，而业务系统怕是要上溯好几层才到 root 。而且业务系统并不需要，也没有必要完备，要不然还要操作系统做什么呢。

驻场外包 /外派大多如此

不同于一般的的管理系统，操作系统是需要自举的。

一个业务系统，你可以把管理权限的权限作为一个一般资源，最初的系统管理员可以只是拥有管理权限的权限的一般用户。系统管理员的权限的配置可以通过直接往数据库写入特定的数据来实现。即使错配，也可以通过操作数据库来修正，没啥大不了的。所以 admin 和 user 也没必要两张表，即使 2 张表，该有的问题还是少不了。除非代码写一个超级管理员。我见过很多这种上帝模式的超级管理员，但我认为这就是个超级大后门，弊大于利，不推荐。

但一个操作系统则不行，root 权限必须是先天的，而非可配置的。因为如果错配导致丢失了配置的权限，就没办法通过配置来修复，只能重装系统。这显然不符合我们的预期。

擦屏幕用送的布，擦键盘就是湿毛巾

@learningman 所以大小周(44 小时)合法的……996 违法，1 是每日加班时间 4 小时，超过了规定的 3 小时，每月加班时间远超 36 小时

两个接口，同一个实现，不过接口在调用实现的时候参数不同

jenkins 一个 job 里面，先 build 好镜像推送到仓库，然后挨个通过 ssh 执行 docker run 。控制好时间间隔，保证在前一个服务可用后再去更新下一个就行了。还 k8s 、负载均衡，搞辣么复杂做咩？

重点是能不能学会，不是干 xx 事行不行。

只要不交易，就割不到我

哈哈哈，我经常盲改代码直接上线。换成楼主，怕是要原地升天。

其实大家可以换个问题：物业费大幅上涨对房价有什么影响？

无论物业费还是房产税，都是房产的持有成本。总得堤内损失堤外补吧