热空气不得往上走嘛。风扇反一面，然后贴近软路由，再降低些转速会不会表现好些？

得买不吸水的，塑料或者金属吧。木和竹的都会发霉，或者得想办法保持空气干燥。

不写接口和静态类型是指没有把每个 api 调用封装成一个方法和 anytype 吗？前者后端稳定可靠就没必要做，后者可能是人家根本不想用 ts 。

话说答案是啥？ 下层不支持全双工的话，上层咋支持，尤其是下层只能单工时，咋双得起来？我感觉得是物理层。难道这个通信模式是特定层的概念？

冷藏都是零上吧？如果还没拿出来，套个密封袋在冰箱里放一会一起拿出来等到常温应该就没事了。已经拿出来的话就自然风干几天吧，充电盯着就行，放电怕烧其他设备就找个货插上放，搞两三轮没事就没事了。

楼上加一 outline 和 AFFiNE 我都不错，个人喜欢后者，还在随缘手动迁移数据中...各个软件之间互相导数据好麻烦

正常来说，充电宝输出的电压在设备请求的电压范围内，电压波动满足设备要求就怪不到充电宝了。电压协商一般不会出问题，这个芯片方案很成熟，所以可能是充电宝用料不行，电路设计不行，不过我觉得概率很低，可以简单测测看。至于手机这边，维修点好像也没下定论是什么坏了，这个不查清楚具体哪坏了真没啥理由怪充电宝。或许这俩都有问题，在一起就翻车了

反正不花钱，觉得他服务不行让他自己取消订单回去呗。你换别的快递下单，都不上门的话再说。

快充头建议看清楚 5V 时输出的持续电流和峰值电流够不够大。HUB 应该不支持快充协议。

docker ，损耗性能事小，污染环境事大。服务端如果还依赖别的服务就直接上 dev container 了，多个项目切换来切换去地，不想老是配环境，而且依赖的数据库的主版本还不一样 QAQ

@fl2d 等下，你这两个网口是指你能控制的某一个设备有两个网口，还是不受你控制的两个网口？
如果不受控的话，最简单的方法就是一台做路由，另一台通过有线或者无线的方式直连它做它的中继 ap 。

那两个路由器设成 ap 模式应该可以？

AMD 迷你主机非常适合，找个价格合适的上车就好。

你找个有兴趣的事+编程捆绑一起搞，可能就培养起来了

不是拿不到 url 和参数的时候，把抓的包拿去重放吗？你开头是不是直接错了

人的精力是有限的，很多公司不需要某一个领域的专家来解决很深的问题，这些公司要的是出活快抢风口。写 MVP 快的应该只有全栈了，能挣钱了才需要考虑质量。

那个缓存不是指远程文件下载到本地的缓存嘛？我感觉是在磁盘的临时文件中存着原始文件内容，拖动进度条时再读到内存处理
我凭直觉猜的，蹲大佬科普

直接用浏览器的请求复制出 curl 代码，丢进去看看能不能正常返回，能的话二分法去参数排除。

这很正常，项目没有愿意负责的人主导就是这效果，一直没人管就烂下去了。
八仙过海，各显神通。