@OrionRies 搞个生词本吧，一个页面标出那么多生词，我想把觉得重要的单词以及当前的句子上下文都给我加到生词本里，我有空了再单独加强复习下，这样就更好了

有用

开启 bbr 试试，也许有奇效。对于高延迟、高丢包的网络环境能大大优化 tcp 的传输稳定性和速率。缺点是流量会略多消耗一点。

设置 u 盘启动就行。移动硬盘没插，系统会自动选择其他的

@sodulty 没搞 ov ，我用的是 http 代理，只对有必要的应用才走代理，嫌弃 ov 全局流量，太重了。

你可以试试 scp 或者 http 等服务能否跑满，能跑满说明是 ov 问题，去排查 ov 。否则还是 bbr 没生效。

你的 ov 是 tcp 协议吧，udp 跑不满那没啥好办法，运营商好像对 udp 有限制

bbr 工作在 tcp 协议栈，爱快做内网到公网的端口映射时，只是简单的 nat 转发，不参与 tcp 协议栈相关参数协商控制，bbr 应该是无法发挥作用的。结论：爱快开了 bbr 只能对爱快自身的一些服务起作用，对只做端口映射的那种服务没用，up 看看你的 ov 是不是部署在爱快里。

这就是典型的多线程多连接能跑满，单线程单连接跑不满。
你 ov 客户端到服务器相当于单线程单连接跑不满很正常。即使客户端 iperf 多线程模式，但底层的 ov 到服务器还是单连接，在客户端侧也肯定无法跑满。
解决办法就是出口服务器上一下 bbr 。家里有没有 Linux 设备？开一下 bbr ，然后 nginx 弄个反向代理，把 ov 以及其他服务的出口都从这台开了 bbr 的设备端口映射到公网。
我之前搞的 nas 也遇到这个问题，发现所有设备只要过了 bbr ，单线程就可以跑满了，非常爽。

查一下 intel 微码是不是有最新版本没更新。我买的 n5105 也是不定期死机，后来更新了微码就好了

有一次淘宝卖水果发生争议，淘宝无脑支持卖家，最后损失 40 多，从那之后基本不怎么上淘宝了

虚焊我有妙招，拆开后壳，给 cpu 的位置垫几层 a4 纸，非常好用的办法

可以

docker 里跑 Puppeteer ，它有转图片 api ，非常方便

webassembly 啊，自带文件系统，完全兼容 unix

@Keppel 已反馈给对应产品，这个肯定是出 bug 了

我司也是搞客户端办公软件的，我把上千万行 c++代码编译到 wasm 了，并且也跑起来了。这块你也可以参考下 photoshop 或 libreoffice 的 wasm 版本，代码量都是这个级别的。
1. 先说体积，编译完大约 100M 左右，用 br 最高级压缩完 20M 左右，这个大小其实以目前网速不算大，配合缓存基本也仅影响首次。
2. 首次初始化稍慢，出去下载的时间，chrome 还会把它编译到一个二进制缓存，后续启动会非常快。
3. 性能我个人感觉能接受，但我司项目不依赖 opengl ，不算是强计算密集型项目，感觉应该有原生 50%左右的性能。
目前项目没有在搞了。。。老板觉得可能时机还有点早，有点遗憾。

每次带三岁的娃随便玩玩那些垃圾街机还凑和

19.9w