22h2 就有。
https://github.com/thebookisclosed/ViVe

vivetool /enable /id:34370472 /variant:2
vivetool /enable /id:39145991 /variant:2
vivetool /enable /id:37634385 /variant:2
vivetool /enable /id:36354489 /variant:2

重启。

说一些字形设计上的问题。

你的定位是一个轻微手写风格的圆角字体，也就是说，它实际上是还算端正的，比如 c 、o 、u 、n 、s 、x 、{的设计都很端正，那么这种端正就应该在每一个字形中正确地体现出来。

首先问题比较大的是小写 a ，它的圆头歪了，这使得它在和一些很端正的字母，比如 sam 并排出现的时候，会有一种 a 是 italic 的感觉。

然后说小写 t ，简单地说，它的视觉中心歪了：当看到 t 的时候，人们预期的视觉中心应该是十字中央，而你的字形右边偏大，使得视觉中心也因此向右偏。

小写 i 的字形也又问题，给人一种 i 的点没有落在竖线，而是微微向右歪的视错觉，小写 j 也是一样。

数字 1 的字形里顶部的折角太小，看起来非常惹眼，你的字体里其他地方是很少出现这种折角的。

小写 e 的上部在视觉里有点大了，会让人感觉 e 的中横线偏粗。

小写 l 的拐角多少有点不安宁。

小写 r 的拐角就特别特别不安宁了，风格上都会让人觉得有些怪。

小写 g 的头有些大，视觉上会过分地被圆圈中心吸引。

数字 0 的斜线看起来让字显得有些过于“满”了。

小写 m 的字形看起来非常局促。

大写 Q…这个分离式的写法我确实是很难适应。

其他的还慢检查，不过总的来说辛苦了。

这个目标下，你能选择的只有 Webview 。

因为别的不说，代码文档本身都是输出成网页的，除非你专门对每个文档做跟进解析，而这意味着补天级别的工作量。

并且，你的优势是：你是本地文档。

在这一点，你就赚尽了打开速度的网络优势，只要再干掉那些弱智的纯 JavaScript 索引的首次加载速度问题，用户就不会再在乎你是不是 Webview 了。

@lucifer9 可以开启资源管理器的多标签页功能了。

还可以把最大 CPU 限制在 99%，这样可以关闭满载睿频，并且避免空载的时候频率犯病。

16mm 已经不小了，你切晚了。

国内吃盐和盐类调味品太多，而且盐普遍都是碘盐，甲状腺结节在很多地方都是区域性常见病了。

所以我建议你一定要和家人说清楚，你得了癌，而且这种区域高发的病，很有可能你的亲朋好友也有。

非常不建议跳过 JavaScript 的任何特性。

非常不建议跳过 JavaScript 的任何特性。

非常不建议跳过 JavaScript 的任何特性。

很重要所以说三遍。甚至我觉得如果你有给政企做项目的需求的话，JScript 的特性也是需要学的。

理由很简单：你初学的时候可以用所有的最佳实践跳过那些坑，但一旦你需要阅读别人的代码，或者调试一些你感觉上正确但实际上却不对的代码的时候，很多时候你必须要了解 JavaScript 中的那些丑陋不堪的部分，并且学会和它们和平相处。

至于原型相关、this 绑定、==的类型转换，至少我面初级前端的时候，这些基础搞不定直接就算了，前端和切图仔还是有区别的。

然后我心里的标准的话，初级和中级前端之间的坎是 webpack 等和 ts 类型体操，中级和高级之间的坎是函数式、通读过英文原版 ecma 标准和 v8 的一些底层。

Google Random Number ？这玩意不是随便想生成多少就生成多少？一个想生成就生成，想重新生成就重新生成的数字，这和黑奖有啥区别……

你真的不如直接抢楼号，或者用未来某一天的福彩体彩或者股票收盘数据作为随机数种子开奖，或者直接拿排列五排列三一类的。

…而且我认真地在怀疑，觉得随手 Google Random Number 都能实现公平开奖的开发者，真的能保证软件稳定不出 bug 吗…

补充：pdm 提供了 poetry 格式的兼容转换，而 poetry 则没有提供。

另外 pdm 的开发者是国人，这一点或许可以影响一小部分判断。但 pdm 的质量实际上比早期 poetry 的质量强多了，用过早期 poetry 的都知道它有多少莫名其妙的小 bug 。

poetry 是一个基于 venv 的依赖安装工具。
pdm 是一个可以基于 venv 也可以在文件夹内安装依赖的工具。

poetry 诞生于各种相关的 PEP 出现前，所以它给 pyproject.toml 里写的内容是私有格式的，要到 2.0 版本才能支持 PEP 621 格式的依赖。

pdm 诞生于这些 PEP 出现后，所以它天生就支持这些新的 PEP 。

越狱了当然可以随便删钥匙链，现在的 app 根本读不了 imei 一类的永久设备信息。

硬解是没有软解灵活的，限制播放速率、帧率、分辨率、b 帧数量、色彩格式都是存在的，并不是硬件里塞了一个 ffmpeg 。

亲测，电池健康度的 80%以下是刚刚好 1000 循环。

也就是说，它实际上记录的不是“80%容量”，而是 1000 次充放电循环，所以它叫健康度，而不叫可用容量比例。

@aero99 完全支持 passthrough ，不过建议是自己试用一下，比询问某项特定功能来的靠谱。

这里最佳实践是直接不给枚举的 0 值定义，并且任由它崩溃。

然后在文档里写明 0 值是 Invalid 的，但是代码里不需要把 0 值起名字为 Invalid ，而是直接从 1 开始，跳过 0 。

这样一来，那些没有赋值的枚举们就会直接崩溃，而代码也只需要在入口的地方处理掉这些 0 们，而不是每次写判断的时候脑子里都要带着这个 Invalid 。

每次看到这一类帖子都会直截了当地推荐 ffworks ，win 平台上叫 myFFmpeg 。

这玩意应该是最完整的 ffmpeg 图形化界面了，功能极其全面。

把结果直接优化成常数倒是也蛮正常的吧，算是 O3 下的常规优化了。

把最初的输入从 0 这个 literal 换成 stdin 之后，coroutine 基本就被敲回原形了，理想中想要看到的把 coroutine 优化成常规代码结构，甚至优化成数学表达式的情况并没有出现，还算符合预期，没有太过魔法。

@ecnelises Rust 是有标准化的，最近的标准有 Rust 2018 和 Rust 2021 ，虽然很多库还是会不要求标准而是要求实际版本号，但早就不是强制 nightly 的时代了。

这…你要是希望 IDE 能在非编译期报个警，估计得是 TypeScript 这种有图灵完备的类型系统的才行吧。

编译期报个警就行了的话，估计各种支持宏的编程语言都能做得到。