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

每天晚上 查找都几乎用了一半的时间，大概 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 了

微信应该会做 SSL Pining 吧？如果深信服中间人了，微信就知道了呀

所以啊，我始终觉得 iCloud 云备份还真是一个备份的手段，就是真的遇到了手机损坏不得不通过它，才用。

一般换新手机的，都直接有线备份 nas 再恢复更快。或者直接机传机

复杂问题，应该是 Surge 使用的 en0 网卡，但是拨通 VPN 后，VPN 新建的虚拟网卡变成了默认路由了吧。也就是流量其实不走 en0 了，也不走 surge 的 tun 了。

@tyzrj766 驾驶培训时超英 +1

B 站推送了很多，但他说得最好（虽然节奏很慢）

一天刷了 800+多啊

标准续航不知道什么时候才有 AMD 呢

@ys746663912 去年新升级 1000M 都明确说了 1T 流量后降速到 300M ，坐标 020

@mgcnrx11 是回复这位 @shyangs

多网卡、虚拟网卡、弄大一些 fd 也可以冲到 100w

请问这种证件照可以用在什么地方呢