补充一下，如果确实就希望这个对象被创建一次，可以参考新版文档的这个例子：
https://beta.reactjs.org/learn/you-might-not-need-an-effect#initializing-the-application

更准确地说，就是如果非常确定一个对象的生命周期不是与组件绑定、而是与整个应用绑定，那么就可以不用 React 的状态管理、并且也最好别用。

(另外，前面提到的 useEffect chain 可能不会很合适，毕竟带来了额外的 rerender)

可以写两个 useEffect ，一个只负责初始化和释放对象，另一个负责在存储这个对象的 state 完成初始化时再开始执行。
上面的 controls 这个变量就会需要从 useMemo 换成 useState 。

@IvanLi127 是这样的，这算是有意这么设计的。设想一下如果这个对象的生命周期如果应该和当前 component 一致、且会涉及到释放操作，那么初始化和回收都应该交给 useEffect 去做。

手上一台 Pro 2018 ，联想口红电源 65 W 无法激活快充，小米的 65 W PD 充电头可以。
……没查过是为什么。

窗口全屏（无边窗口模式），渲染分辨率不变，仅缩放填满屏幕；
普通的全屏模式，渲染分辨率跟随系统分辨率设置。

整薯条已经是家常便饭了，换一张图
https://i.imgur.com/1SJnb6U.png

虽然不知道怎么做合适，但先丢个 npm 包在这
https://www.npmjs.com/package/@ctrl/tinycolor

如果要用 HSL 来做过渡、然后转换成 HEX ，这个包可以帮忙。

https://gist.github.com/MossTheFox/eb9ede4c622c4ea65493147efad72ff0

安装两个包：
npm i express http-proxy-middleware

如果不熟悉 Node.js 的话，要做的基本就是下面这几步：
mkdir temp
cd temp
npm init -y
npm i express http-proxy-middleware

目录结构：
📂 temp
- index.mjs (此文件)
- package.json (npm 命令创建)

运行: node index.mjs

用过一个 node.js http-proxy-middleware 包，可以结合 express 很快地搭一个本地反代理来测试。这种需求下，可以接管实际请求返回时的数据，写一个随机报错 (可以是发送请求之前报错或者是收到响应之后丢弃然后报错，看哪种合理)。

微信这种没有云同步的程序，要是有重要数据那得多端备份才行。手边有大存储的水桶机或者平板之类的设备，挂一个微信上去都是好的，平板和手机可以同时在线。

用过 switchroot 团队给 Switch 定制的 LineageOS (TV 版和 Pad 版都有)，可以用手柄右摇杆模拟鼠标。不限制必须是无线手柄。
不过不清楚是怎么实现的。

不过，如果最终需求只是需要用鼠标，那直接找 USB 口吧。不会有高度定制的安卓 TV 把 USB 鼠标的支持给砍掉的。前文的飞鼠也是鼠标，只不过做成了遥控器状。说不定带的功能键刚好也可以控制 TV 系统的界面用。

@haoxuexiaoyao 转 PNG 或者 WEBP 的时候在输出设置展开的菜单那边，选择丢掉透明度信息就好。
不过，对于 PNG 可能反而会让图片体积增加，这个和当前用的处理引擎编译的版本不支持压缩成 PNG8 有关，貌似是因为 license 的原因没有内置。

对于一些图片文件的快速操作，之后有细节想法了的话可能会加进去，方便处理图片的时候可以跳过那一长串设置菜单。

身边的亲戚朋友在过年期间打牌的输赢记录直接刻在微信转账消息记录上了，想想倒也挺合理

@tool2d 确实，如果调用原生 exe 的话效率和稳定性会高很多，而且文件系统访问也更方便。
不过，处理图片的原生应用已经挺多的了，这个网页应用我一开始想的是看看能不能把一些基础功能直接搬到浏览器中运行，毕竟浏览器在各个平台上都有稳定支持、而且网页应用可以即用即走。所以就这么做下来了。

@12101111 引擎报错，应该不是达到了浏览器内存限制，更像是在动态申请内存时达到了 Emscripten 设立的限制（不确定）。因为没有自己编译测试，出错的位置只能定位到 vips_write_to_buffer (输出) 这一步。
指定输出 webp ，可以很快捕获到 OOM 错误，但用例如 JPG 输出的话，似乎直接就冻住了，资源管理器里面内存上升的 1GB 左右内存降下来之后，运行引擎的 worker 依然是阻塞状态。

用相同内核版本的命令行工具在本机进行转换并不会这样，速度很快、而且也没有观察到夸张的内存占用（ vips 本身不会整个地把图片读入内存）。

所以，这大概是 WebAssembly 版本特有的问题。因为大约算是极端情况，所以也没有去细究。

确实就是这样设计的。统一左对齐而非居中对齐的好处在于，多个磁贴竖着排列的时候，文字统一有左侧一道对齐线，对于感官上的文字浏览效率是更高的，可以更快地定位要找的程序 (尤其是对于早期 Windows 10 的纯色色块风格图标来说，通过文字辅助辨认是不可忽略的)。
可以试想一下常看的 API 文档的左侧边栏菜单那种，如果文本变成居中排布，不考虑美观问题，阅读起来的效率也会有些下降。

“祝各位大佬在新的一年里 Windows 开机蓝屏，Linux 开机 Kernel Panic ，Mac 开机五国，服务器 iDRAC/ iLO/IPMI/KVM 全失联，”
后面的忘了。

Google 找了下，呐：
https://i.imgur.com/IccGAUI.png