猜猜应该是 mtu 的问题

剩余时间 8 个小时的路过。。。

路由器没断网，就再加一个可以连接的渠道，怎么方便怎么来。
路由器断网了，用啥 vpn/frp/ipv6 都一样。那唯一的解法只能上 4g 路由器整个备用线路。
再极端一点，考虑到临时断电导致的失联，那还得额外加 UPS 。

我感觉趋势就是以后“自动化测试”的程度会越来越高，也会越来越好，同时也看好这个方向。或许将来基于 AI 的自动化测试可能是一个比较好的方向，不管是 API 还是 UI 的自动化，有希望能解决现在很多自动化的不足。

但是说实话工作几年了，基本上没见到过“优秀”的测试工程师，我现在对测试的要求只有两个，1. 能理解产品和理解业务 2. 能写测试用例 。

另外也是建议你先检查一下你这里说的”性能压力“是什么，看看具体性能的瓶颈在哪里，有时候一个代码上的小优化，就可以起到一个立竿见影的效果，也有时候调整一下服务器规格，比如增加内存使用读写更快的磁盘也能在某些情况下大大的缓解性能压力。

如果是因为机器性能和部署的原因的话，看了你的描述，我感觉可以试试把画图这部份抽出来部署到函数计算上。

这样成本可能会比现在降低很多（ 20 台服务器说多也不多，说少也不少了），性能的话可以写个 demo 测测看情况，实例数量可以随着并发增加而增加，而且不需要维护。

感觉没啥必要。

你已经有电脑然后又要备份的情况下，如果是因为磁盘空间不够，那么建议是买一个几十块钱的硬盘底座，然后根据你的需求加硬盘。

不过我看 op 的帖子，心里大概有答案了，这个 nas 是不买不行了。。。

主要用 Chrome ，其次 Vivaldi ，再其次 edge | Safari | Firefox
看情况几个浏览器都会用到书签主要集中在 chrome 和 edge 上。

改成这样：
location /api {
proxy_pass http://localhost:3000;
}

现在这行情，外包也不是想进就能进的。。。

就算再回到那天，大概得到的还是一样的结局。

我觉得这个是一种很 low 的行为。

实现方式不一样，使用方式不一样，都是基于浏览器的

我之前也做过一个类似的浏览器爬虫。。。

@zyxcompany 图片/文件可以不用上传的，js 可以在浏览器上处理。

估算就是需要很多其他的数据来作为估算的依据，不谈具体的业务场景没有数据来源的“估算”就是耍流氓。

有的场景就是上线后 100%的客户端一整天都在线，有的场景就是 80%的用户每天 9 点在线其他时间都不在，有的场景就是每年只有 1 个月 PV 暴增 10000 倍。没有什么统一的算法能衡量这个东西。

如果“估算方法”能量化的话，那么可以说用 20%的方法 可以解决 80%的系统估算问题。

实名制提交代码，实名制开源，再加上公安局备案机制。手动狗头