@concernedz 候补主要不确定能不能候补到，而且也判断不出来,就挺坑的

@dqzcwxb 我说的履约是 12306，可以和各大支付平台合作，我成功购票了你划拉钱，我没成功购票我候补，你就别让我先预先付款了，对我而言你就是无法做到百分之百履约，没有道理先让我给你钱啊

@dqzcwxb 这么说吧，在程序设计上一码归一码，如果说有机器恶意候补所以不显示人数，那么应该优化的是怎么判断恶意机器，如果这玩意无法判别，所以才在业务角度出了这么个昏招。再说出去从程序设计角度真的无法判断恶意机器候补么，可以通过详细的规则+用户身份信息+平 ip 去区分把，你要是 12306 的开发，你知根知底当我没说，12306 对于咱来说都是黑盒，你咋就这么理直气壮的知根知底了呢？

@dqzcwxb 懒的怼你了

@dwlovelife 预售跟我买票还不太一样把，预售是我确定买这个东西，电商也是有履约的，我买的一定会给我，不然用户会要求进行赔付的，我预售一件有可能买不到的东西，有何道理要我先把钱给你，你到了买不了再退给我？这玩意在程序设计上完完全全可以做到一手交钱一手交票，无知导致无能狂怒这句话真是把我逗笑了，我们作为每一个真真实实存在的用户，这玩意做的好么？如果做的不好，用户不能反馈么，你的世界真昏暗啊

@dqzcwxb 不给人数就能防止软件利用数据进行恶意候补了？

最主要的问题 你删除的数据事实上在数据库里是没有完全释放的 相当于无故添加了几行隐藏数据 然后页合并和页分裂的时候 也会受影响

多问一句 要是 20 个服务器集群这种 怎么 tail

有几个人 做电商业务 有几个电商业务场景需要秒杀 需要电商业务又需要秒杀场景 然后这个活给你做 再经历过真实生产环境的考验

@sadfQED2 高峰 QPS 7000-8000 正常 10 多台服务器就能搞定的，为啥要浪费 1000 台机器的成本干这事

我的想法是 部门和岗位 跟权限没有关系，只让用户和角色挂钩， 权限是作用于角色的 角色是作用于用户的 这个能做到最细粒度

@tctc4869 看你的角色 能作用的范围 是直接作用于用户 还是跟部门岗位也有关系，其他的就走 RBAC 那一套就行了

员工一对多部门，员工一对多岗位，部门和岗位不建关系映射，如果要查关系 通过部门找员工去查岗位

低代码 就好比 一套机器让你做菜 稍微变个菜系 或者 或者需要临时加点什么 做点复杂的 完全应付不了 大型系统的业务复杂度 比如电商 你用低代码给我干干？ 只能帮你干点常见常用的 程序员被低代码或者人工智能取代 就是个笑话

大厂绝壁进不了，除非你很牛逼，或者跳的全是大厂

@knightdf 对，确实，有但是机会相对肯定少很多，难度也大很多

@zouzou0208 可以的，哈哈，我收藏一波，感谢

@knightdf 这个是相对的，一旦你有能力挣 30 、40 乃至更多，你就会觉得 20 少了