nginx

没有的，不存在的，别想🍑了。找到问题的关键，解决它就行了。

楼主你们没事干了吗？
滚动条上面滑块高度动态还是固定不是 UI 的事情吗？这个产品越权了吧。这种可有可无的视觉效果，但凡是个靠谱的 UI，就不会去花时间在这上面。

springBoot + openfeign + springcloudAlibaba + nacos
技术栈不重要，不予置评。

gitlab commit 强制规范。很好，需要坚持。如果不能推行，可退而求其次，逐步推进。
git commit before 强制跑 soner 。能跑最好，不能跑就算了吧。
测试一个功能一个服务的实例和所有基础服务。不需要，基础服务本身应该是稳定的，没有必要每次都去测试。
强制所有模块拆分成为一个，一个 git 远程仓库。一个项目一个仓库就行了。
通过 ELK 采集日志集中分析和查看。必须的，但更重要的是日志的格式和内容。
对新表上线必须模拟日增数据。不需要。
对服务的监控和熔断，限流。不是必需的，等有需要再加上即可。
git push master 必须通过所有回归测试。不太现实。
所有服务必须有基本的 readme.md 介绍。需要，强制推行。
所有的服务必须有版本发布管理。必须的，通过工具来管理
所有的部署必须通过 git 钩子自动化部署的。不好，还是手动点一下发布比较现实。
模块的更新必须共同开发的同学一起 code view 。估计顾不上。
模块的调用必须通过 feign 或者 MQ 来完成代码的解耦。这是必然的，而且在服务内部，不应该存在模块间的调用。如果存在，那就应当抽离成一个公共的方法。

其实吧，一个项目能不能迅速地开展，取决于你有没有一个成熟的体系。项目能不能顺利推进，取决于你有没有足够的现成可用的、稳定可靠的基础功能模块或服务。也就是说，只要你有一个成熟的技术体系，而且这个体系已经具备了常用的，可开箱即用的基础功能模块，你做什么项目都不会有太多问题。

20H2，没有检测到更新。。。

调岗是需要员工书面签字同意的。公司这么干，就是送人头的。。。直接去仲裁吧。

@whileFalse 没实际用过函数计算，但这个连接池都有问题也太夸张了吧

所谓函数计算，就是你只管写代码，不用管运维而已。价格可比买 ECS 贵多了。自己稍微懂点容器和自动化部署，就没必要用函数计算服务。

@RIDESU
@Milicense 为何我这里没有镜像模式，只有扩展？

我不能理解的是为啥外接显示器后内置屏幕的字体会变小？

好久没用 EF 了……我记得 EF 有三种设计模式：Code-First 、Model-First 、Database-First 。貌似只要不是 Database-First，就可以自动修改数据库表结构的。

除了长租房，还可以短租、酒店长包、青旅。所以不用着急找房子，先住下来慢慢找都是可以的。

对于商家来说，大部分都是 B 商品，A 可能是一些尾货，C 不需要多谈。

不是啊，假设你商城中有 A 、B 、C3 种商品：
A 商品你需要在用户下单后立即发货，所以不能超卖。在库存下降到保留数后就不能下单了，以免无法发货以及影响售后换货。这种就设定 1，下单扣预警库存。
B 商品由于有一定的价格优势，采购周期很短，发货稍慢一点用户也不会退单，或者厂家可以代发货，那就可以允许超卖。只在支付后扣实际库存，而且允许库存为负数。卖就是了，能发货的立即发货，不够的话采购后发货。
C 商品是虚拟商品，压根不存在库存这个概念。

那么，这三种商品你能同时卖吗？你的设计不能，我的设计就可以。

搞一张会员表，用户表里面加一个会员 ID

@wayn111 我定义的 3 种库存属性已经涵盖了所有的场景需求。如你们这种需求，你只需要把需要及时发货的商品的库存属性设置为第一种就行了。同时，并不妨碍第二种、第三种库存属性的商品同时存在啊。

商品库存其实可以分三种，我的策略是：
1 、卖完不能采购后发货。无库存不能下单，下单扣预警库存，支付扣实际库存；
2 、卖完可以采购后发货。无预警库存，支付扣实际库存；
3 、虚拟商品，无库存。随便卖，不扣库存。

憋折腾了，数据一致性是一个非常复杂的问题，不可能存在简单的、轻量级的解决方案。所以我不会去试图解决这个问题，而是针对临时性的系统故障，利用延时队列做一个简单的重试。重试成功自然万事大吉，失败了呢？失败了就人工干预好了。。。系统跑了 3 年多了，还没干预过呢