第二种取结果时需要用数组下标，第一种不需要，核心问题是：正则作为一种嵌入式语言，是不是提供了足够的抽象能力，以及，这种抽象能力是不是对宿主语言无依赖

任何旅行，如果值得出门前花半小时查攻略，也就值得背哪怕黑卡入门级提升一下画质

弄个电暖器，对自己好一点

确实不能最小化，扩展和油猴都不行，出过好几个加料的案例了

懂了，技术决定了：一个屏幕横着没有果冻，竖着一定有，反过来也一样。苹果这次改了封装方向，其实是翻车了，原则上，不应该把果冻放到划动最多的方向。解决方法只有一个：换个方向拿 iPad

「每次你用正则解析序列化的结构数据，就是重新写了一次这种数据结构的解析器」

每次想写一个常人难以理解的正则时问问自己，你是解析器的作者吗，不是的话，用别人写好的解析器

每次想写一个常人难以理解的正则时问问自己，你喜欢读复杂的正则吗，不是的话，其他人也不喜欢

@hanguokai #37 用户和任何一个最危险的网页之间只隔着一个点击，这和有人审计的扩展，和必须主动安装的原生都相去甚远，拿来类比并不合适

引入一个映射整个文件树到 BOM 的 API 是否合理？我看能举出不少正当的使用用例

其实是历史遗留问题，现在安卓手机上微信通话的操作逻辑就是类 CallKit，无需解锁无需切换 app 直接接听；苹果大概是早期被监管之后，再也没有试图推动

不是离岛才能免税么，本来对非游客也没用

@Z1on #12 原来网页只能在自己的标签(视口)检测用户的状态，新的 API 允许网站检测用户在其他标签，其他软件，其他屏幕的状态，实际已经破坏了业界对 Web 安全的约束

这种 API 总是有用户态的方法屏蔽，也有开发端的方法反屏蔽，这是前端对抗的范畴，负责任的浏览器应该在系统层面拒绝这种越界提案

有些手表模拟门禁的操作是，先从安卓 NFC 手机读取，再传送到手表上，没有安卓 NFC 手机就做不到了。能直接在手表端读取并模拟门禁的，我知道的有华米

可以用，小米的充电器支持 PD 协议

@godpeo #111 宋体在小字号时确实是优于雅黑的，毕竟是一个像素一个像素画的。雅黑是配合当时出现的大尺寸低分屏使用的，在 16px ~21px 字号下，宋体就没法看了，而这正是大多数人的正文设置

另外就是 Web 沿袭的 12px 设定实在是糟粕，损害了一代人的视力

雅黑出现的历史时机：
1. 之前是小尺寸低分屏，对应宋体一类的点阵字体，描点精确锐利；
2. 之后是高分屏，对应 Noto 苹方等纯矢量无微调字体，曲线光滑平整；
3. 中间正好是大尺寸低分屏，需要更大的字号，但是点阵描字工作量无法负荷，矢量字体在低像素下拉不开；
4. 雅黑此时出现，用矢量曲线计算框架，辅助专门为低分屏 LCD 优化的微调技术(ClearType)，效果拔群；
5. 雅黑成功的实现了设计目的，至今仍然是大尺寸低分屏最佳字体之一；
6. 不能抛开历史背景，单纯凭个人喜好谈论设计问题；

如果不给 axios 设置 responseType，那么 res.data 的类型是 string，这里是文本化的字节流，也就是乱码，后续怎么处理都不能用

给 axios.post 传递第三个参数 { responseType: 'blob' }，这样返回值是 Blob 对象，不需要再手动构造
axios.post('http://localhost:9080/compress/png', formData , { responseType: 'blob' } )
.then( res => {
const blob = res.data ;
const url = URL.createObjectURL(blob);
......
} );

以及，如果因为某种操作，返回了符合 new Blob 构造的输入值，type 参数也应该是 image/png，而不是 text/plain