@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

喔，好耶！

用起来确实丝滑，现在很多搜索引擎搜索到的信息页面基本都是半个屏幕塞满广告的那种模式，这么优雅的网页应用好难得的。

要说建议的话，例如图鉴和搜索页面那边，顶部输入控件也许可以用 sticky 布局保持在滚动容器的顶部，这样就更方便查图鉴翻得靠下的时候更换查询条件了 (不过移动设备手动滚动到顶部倒也不费时间)。

顺便，如果继续更新的话，也可以适配一下 PWA ？这样在绝大部分不是很旧的浏览器里面就可以添加成桌面图标全屏幕运行了，iOS Safai 也支持，体验不比原生应用差。
可以看下这边： https://web.dev/progressive-web-apps/
(基本就是添加必要的 meta tags 和 manifest.json, 以及配套的图标，太进阶的特性因为不同浏览器的兼容性问题可以无视)

USB A 口的输出功率很小，USB 2.0 最大电流 500 mA ，USB 3.x 最大电流 900 mA 。

不过，刚刚试了下，手边的电脑 C 口是可以 5V 3A 输出的，可能这个才勉强够现在电子设备的平均快充速度的底线。

也就是说，比起考虑能充几次，不如先想一下这个速度会不会有些慢过头了……顺便再考虑一下低电压充电的高线损。

如果准备出远门的话，还是多买一个支持快充协议的充电宝吧。

屏幕 nb ，性能不清楚最近几代如何，但之前的 Pro 系列是经常吃散热的亏的。

手持肯定会偏重，而且考虑到发热，我有个 Surface Book 2 15 寸型号，架成绘图模式的时候手掌贴着屏幕日常被烫得难受，所以现在动笔的活儿全挪到 iPad 上去了 (iPadOS 在非预览版系统下不会出现屏幕烫手影响书写的情况)。

要说最大的优点，扬声器、屏幕显示素质、键盘设计，然后大概就没了。不过，这些优点也是其他 Windows 设备少有的。

触摸屏对于 Windows 来说…… 至多就是整网页开发的时候可以更灵活地调试触摸交互，其他的话个人感觉日常没有用到的地方。换屏幕的时候被第三方坑了之后，顶部会出现幽灵触控，就把触摸暂时屏蔽了，只保留了笔触。

……另外顺便也提一下自己的设备，反正也刚好是同一系列的产品。Surface Book 的 CPU 和显卡配置搭配给人一种小马拉大车的感觉，不知道是不是错觉。Windows 界面是核显渲染的，开透明效果就日常掉帧。CPU 性能就那样，然后，1060 显卡跑分不如惠普某 1650 的笔记本。Blender 用起来挺可以，大型游戏的话反而容易遇到 CPU 过热导致逻辑帧数 (这么叫准确么? ) 跟不上、游戏掉速度 (不是仅仅掉帧了)、音频断流。

Pro 系列不是很清楚，我这就一台垫桌腿都嫌碍事的 M3 底配 Pro 4 ，已经不知道啥时候从某鱼捡来的了。因为底配的无风扇设计，夏天你可以试试在户外开机看看…… 目前已经落灰许久。

我来捉虫了 (不是来捣乱的 别太介意……)

Bug 相关：
- URL 直接访问没有适配 React Router (GET https://www.wedtr.com/register -> 404)
- 登录注册表单的 label 把输入框推得有些靠后了
https://i.imgur.com/FSFdlMM.png
- 邮箱按理说是可以有下划线的
https://i.imgur.com/JYfzZ2T.png

用户体验相关：
- 网络请求出错的情况下，没有直接的提示 (以及，默认超时时间挺长)
https://i.imgur.com/NkC78kd.png
- 以头像上传按钮和发布按钮为例，上传中的状态下缺少提示，且按钮没有被 disabled (可以被再次点击导致重复请求)
- (以及，对所有人可见的开关状态不会被保存)
https://i.imgur.com/Ae9LI4K.png
- ……配图为什么会限制图片的比例尺呢
https://i.imgur.com/iwNqc8e.png

顺便：
- lang
https://i.imgur.com/aD31a4x.png

更正："此时的任务队列是空的" → "此时，当前的回调函数并没有直接进入任务队列"
(正在执行的也是一个宏任务)

@zhanglintc

我不确定自己的解释对不对，所以…… 如果有路过的人发现有不准确的地方，麻烦一定要指出来一下，感谢。

setTimeOut 注册的是 marcotask (宏任务)，它的行为是这样的：
- 在执行到 setTimeOut 的时候，定时器会交给 JS 引擎去在指定的将来 n 毫秒的时候，将 callback function 推入宏任务队列 (**注意** 此时的任务队列是空的，等待定时器的过程不属于 JS 的任务队列里的任务，注册的回调函数才是)
- 只有在当前的同步语句执行完成 (即当前的宏任务结束) 之后，宏任务队列中才会开始执行下一个任务

也就是说，即使这里在两个 setTimeOut 执行结束后，阻塞了超过 10 ms ，实际上宏任务队列也是会按照注册的时间将任务推进去的——只不过到时间了的时候，当前的宏任务还没有结束，所以回调函数不会按预期执行 (但确实是按预期的时间顺序推到了队列里面，所以是打印 2 的任务在打印 1 的任务之前被推入)。

(这整个代码块需要被视为是一整个宏任务，sleep() 执行完毕之前，宏任务队列里面的其他任务不会继续执行，但不代表宏任务队列不可以被推入新的任务。进入队列的时间不受 JS 阻塞的影响，JS 的阻塞影响的只有开始执行的时间)

啊，以防对于前面描述的宏任务的概念有些理解不到位，这里放个参考链接：
https://stackoverflow.com/questions/25915634/difference-between-microtask-and-macrotask-within-an-event-loop-context

我挺确定 Airpods Pro 的耳机和盒子的耐摔程度是很高的，只要不一脚踩上去的话轻易不会有损坏。
至于充电盒刮花这种，多刮一阵子不就成亚面了嘛，不用计较。虽然卖得贵，但也当消耗品用吧，不然买了电子产品还要一直伺候，蛮憋屈的。

啊找到了，这里： https://juejin.cn/post/7171002835016892453

Javascript Promises are Eager and Not Lazy: https://tusharf5.com/posts/js-promises-eager-not-lazy/
(就是一楼所说的那个)

同样的题目我记得在掘金上面看到过一个细致的题解，客户端似乎没有浏览历史记录，所以链接也没法找了。

@SchneeHertz
确实，这个界面提供的实时信息也很详细，顺便感受了一下 很 飞 快 的传输速度 (显示的实际实时速度是能达到 10 KB/s 以上的，取决于设备的二维码刷新率，但越往后的有效数据会越少，最后的个别分块会等待很久才能补齐)。

也就是说，确实不是不可行，不过现在常见的二进制文件体积少说也是数百 KB 起步，真用起来倒也挺不够带劲的。

和内容农场一类的，热门内容的中文搜索结果不堪入目已经是日常了

确认有效 (移动端 Safari)

贴吧网页版肯定是有维护的，往更烂的方向而已。以前不登陆可以无限制浏览，现在帖子的第二页开始所有楼中楼都全部不显示了。