训记

支持

> 如果存款利率也是固定每年 4%，你手里有 100w 的话，按照 30 年还款计划，存款产生的利息总和正好贷款利息总和相互抵消

这个假设不对的。因为存款是“到期一次性还本付息类产品”。房贷是“分期偿还类产品”，就算他们都是 4%含义都不一样呀

因为 op 把“响应式 Reactive” 和 “异步非阻塞” 的概念 混淆为 它两个是一个意思了

Project Reactor 的响应式里面，当 subscribe 时，一系列的操作会一个接着一个去执行。但这些操作都是我们自己写的代码，还是需要确保这里自己写的代码是“非阻塞”的才行。否则，就会像你举例的一样，sleep(2000L)后发现阻塞了。
还有的是，除非显式的调用 publishOn / subscribeOn 等方法呢，否则都是在调用 subscribe 的当前线程上执行的。也就会造成该线程被 sleep 阻塞起来的感觉

> 但是 gpt 告诉我 filter 之间可以是并行的

这是错误的

@xiaocongcong 最近我也有类似的困扰，在外侧玻璃花了 1 个小时把油膜都干掉。结果一上车从内侧往外看，还是油乎乎的。

已经不知道怎么分辨究竟是外侧的油，还是内侧的贴膜花了。

去 YACD 面板，左边第四个 Connection 界面，看看走的什么规则

二.内容收费 和 三.物易钱，都不能算是 睡后收入啊，这还是要付出很多劳动的

@zed1018 spring.factories 换成新的 import 文件。

因为这个是 Spring Boot 2.7 的时候换的

居家隔离时，想喝咖啡都没豆子了，想吃薯片都没得买

“这个 controller 已经加了 @RestController 注解，会自动实例化”

这句话就不完整，自动实例化的前提是 @ComponentScan 包扫描到这个类

跑个 Surge 网关废物利用

最烦的是下载的对话框一直强制在最上方，怎么也踢不走

每天晚上 查找都几乎用了一半的时间，大概 10-15%的电量。有没有什么办法可以关闭查找的耗电😂查找里面有 iCloud 家庭共享的人的设备，以及自己的 iCloud 设备 6 个。感觉好像是这么多设备们不停的在互相查找

说明还有一个包依赖了 4.2.8 版，并且依赖的传递性路径更短，或者它的顺序在 pom 里面更靠前

@coala https://tailscale.com/blog/how-nat-traversal-works/

一个 HTTP 一般包含 HTTP Header 头和 HTTP Body 内容体，WebFlux 要处理一个请求，需要先解析（完整读取） Header 头的内容，最起码第一行 URL 地址要读完，这样 WebFlux 才知道要构建一条怎样的 Pipeline 来处理这个请求。

说个简单的情况假设请求的 Body 是一个 JSON 格式的数据，可能 pipeline 流水线就这么简单：

request -> json parser -> response

在构建完 Pipeline 之后，触发 subscribe 的是最下游 response 的 write ，response 响应要知道要写什么内容返回，那就会 request 上游获取完整的请求的 JSON 的数据（这时候可能只是 request(1)，它只需要一个 JSON ），那上游获取 JSON 数据的假设是一个 JSON Parser ，它自己内部应该就可以控制每次请求多少字节的数据来做 parse 了，这里就可以控制 request 每次的量。通过每次的量和次数，就能控制上游 读取 request 的速率了。但是这个读取速率都是从缓冲区读，不能控制对方给你发的速率的，那是 TCP 层的事情了。

看来可以拼车，有人发车吗？

经历过麻木写 Interface ，然后变成觉得都是一种了就不写 Interface ，到最后维护的项目需求确实增长超出预期又退回去老老实实写 Interface 的阶段

这种设计模式嘛，你不知道后面会不会有用得上的时候，当真的用得上多种实现，就会庆幸当年没有偷懒写一个 Interface 了