盲猜：
视频编码损失好衡量，有一堆现成算法可以非常精确的比较压缩造成的损失
音频编码损失全靠玄学（

来用我的定制雅黑（指用更纱黑体取代微软雅黑），附带全字重（不过要用起来得做一些注册表 hack
https://github.com/codehz/YaHei-Build/tags

这加密是怎么做到比源文件大 33%的
一看后面做了 base64 ，我寻思 r2 这玩意又不是限制不能上传二进制，这 base64 有啥用

passkey 是直接不用密码了，用 windows hello 来保护密钥（也就是依赖 tpm 等特性支持）

eyJ 一看就是 json 开头的{"啦，结合斜杠特征，那就是 jwt 啦

用虚拟机的快照不好吗）

网页能统计每个网站的使用时间吗

https://www.nirsoft.net/utils/hot_keys_list.html 这个功能比较单一

这不先来一波 CRDT
https://hal.inria.fr/inria-00609399v1/document

inline 的语义早就改了，甚至和 inline 这个词本来的意思都不一样了，强制或者建议两个都不是，唯一的用途就是打破 ODR 可以多次定义，正因为如此，inline 也可以被用在变量上了

@ElmerZhang 那不如直接 update xxx set amount = amount - A where amount > A (

RGB 不好渐变，用 HSL 不就好了，直接把角度填上去）

不过你发的这个图显然是翻译的锅，原文应该是 alternative frontends

所以这时候就需要科技来解决了
自动取标题和生成摘要的技术已经有了不少发展，理论上以后确实可以不需要特别区分标题还是内容

虽然不是很懂 interner ，但是稍微查看了下文档，这应该要用 newStrongInterner 才对吧。。。

虽然但是，已经有好多“支持扩展的”android chrome 浏览器实现了，有做过对比嘛
(比如 kiwi

@nomagick 新的设计改了很多语义，比如你不能在装饰器里拿到原型，也不能在类装饰器里拿到属性 /方法装饰器的数据，最重要的是，不能改变成员的属性，你不再能把属性变 getter setter ，也不能增加删除成员
基本上和 ts 的装饰器不一样了，现在 tc39 的态度就是不应该在严肃项目里用现有的装饰器

Babel 7 supports the decorators proposal presented to TC39 in the November 2018 TC39 meeting. It's fine to use these for experimental purposes, but they face significant performance issues, are not yet widely adopted; we don't plan to continue pushing for this proposal in TC39. As such, we recommend against using this version for serious work. In follow-on proposals to add more built-in decorators, we hope to be able to recover the extra functionality that the November 2018 decorators proposal supported.

没用装饰器是对的，装饰器的问题在于，它没准明年就会被新的草案代替，按照 ts 官方的意思，很可能最早 24 年（假设装饰器 23 年出）就会全面转向新的装饰器草案（毕竟一直说旧版的是 experiment ，不算稳定接口的一部分）

最简单的方法就是判断 sim 卡地区呀，没 sim 卡就当作模拟器，模拟 sim 卡地区可麻烦了，至少能挡掉一大堆人