你活着累不累？

upstream 我记得是有参数配置域名解析 resolver 的缓存时常的，你可以把这个时间调短一点。
对于访问到失效 ip 的问题，我觉得你可以配合 nginx 的故障迁移来解决。
将失效 ip 产生 502 503 504 的 http 请求迁移到其他节点下。

如果你的池子里节点总是有一台能正常访问的话，那么基本都没什么大问题的。

lz 有观察过白色背景全屏下，四边有阴影黑边的情况吗？
我的上边有暗边的情况，打算换了。

现在的人都懒到官方文档都不肯去看一眼，光明正大伸手了？
https://redis.io/docs/manual/transactions/

国内的网络环境我建议你还是对敏感数据加一下。
一是国内很多公司的机器是装有监控类进程的，而且还加了自签根证书。
二是的确会有很多小白用户不知道中间人攻击直接无视浏览器安全提示。

笑死我了，楼上的回复真的是一针见血。
lz 就好像十年前 webkit 开始要大行其道的时候，搞了一套华丽的 ie6.0 兼容解决方案一样。

因为你这种 b 超检查其实去普通社区医院就行，没必要跑这种大医院。

说实话我不信你真的精通这些。
基本上要么都是自己写过一些 demo ，要么就是工作里别人封装好的用一下。

到头来不就是在为难打工人吗？何苦。

其实 b=a.getB() / a.setB(b) 这种写法完全可以替代成 b=a.B / a.B=b

找罪受。。
idea 社区免费版都比 vscode 强不是一点半点。
聪明的人用对的工具写出牛逼的程序来证明自己厉害。
笨的人用冷门抠脚的工具写 helloworld 来证明自己与别人与众不同。

直接买顶配，未来 6 年不纠结。。
买低配，过 3 年我估计你就会想换新机。。

问一下，还花时间在编程语言这个级别上 battle 的，一般都是毕业几年的啊？

RC 级别，一个事务里每次 select 可以获取到其他事务已经提交的数据。
RR 级别，一个事务里每次 select 获取的数据都是快照，可以重复读。
update 、delete 、select .... for update 里 where 后边的查询都是取得当前读，也就是最新的数据。

我觉得你的困惑是，RC 级别下，可以读取其他事务已经提交的数据是不是违反了数据库的隔离性。
其实数据库的隔离性不是 100%完全隔离的，规范里定了 4 中隔离级别，根据自己的业务需求和使用场景来选择。
实际上大部分的需求都是可以通过乐观锁、悲观锁等手段来实现数据隔离。

甲状腺癌主要分乳头癌和滤泡癌，其中大部分都是乳头癌。
乳头癌因为生长比较慢外加有效果很好的靶向药碘 131 ，所以这玩意治愈率非常高，目前已经被移除重疾险范围。

没必要。
我用微软双拼 3 年了，中间用过自然码、小鹤之类的，最后还是换回了全拼。。。

现在的搜索引擎都没有一个针对双拼优化的，搜一些东西是真的没全拼方便。
其次双拼的输入效率并没有比全拼高多少，现在各种胡里花哨的联想功能、词频都是针对全拼优化，比你还了解你。
最后是 ios 滑动输入不支持双拼，所以我就换回全拼了。

少打字符啥的其实全拼联想都能帮你做到。

@JimmyLX 钉钉 6 月底的版本就能检测是否是 gpx 定位的了。
我后来是用其他设备的旧版本来打卡。
禁用自动升级吧。。

@duoduo1x 我用 mac studio 内置的是实时的。
但是用 ultrafine 4k 就有延迟。。。

项目规模不大的话，数据库直接 join 什么其实还是很好用的。
瞅了一眼楼上为什么好多不推荐 join 的感觉都没说到点上。

我自己的经验就是：
1.大项目需要分表分库，join 在分库分表的情况下处理起来很麻烦。
2.缓存问题。比如某个订单列表里包含有用户昵称，这个昵称因为是通过 join 查询因此也被缓存起来了，假如某个用户改了昵称，那么很容易会忽略掉这些缓存造成不一致的问题。
3.用业务代码替代数据库 join ，也能方便日后服务化。比如用户系统和订单系统以后做拆分了，vo 需要同时展示订单信息+用户信息，那么就可以根据关联的 id 调用其他服务来获取数据，减少重构成本。（ UserDAO.findById -> UserRemoteService->findById ）
4.一般情况下，join 是不会直接 select *所有字段的，一般都是按需选字段。不同的业务需要取不同字段的话就要写不同的 join 了，还不如直接 id 直查关联数据，按需选取。

至于你说的多表关联，一般是要求不超过三张表 join 的。
像商品-订单-用户，就是典型的用户-商品多对多关系，订单可以看作是关联表并且额外维护了其他的信息。
但是像角色-角色权限关联表-权限，也是一个多对多关系，但是由于角色-权限本身是紧密耦合的，不会像商品用户那样可以独立作为一个系统，他们的关联表也不需要维护额外的信息，所以这种场景肯定还是 join 更合适。