有没有可能高温下硬件会提前损坏？而且坏了肯定没保修了，即使 cpu 本体能承受得住，cpu 周围的部件也不一定能用，比如有些风扇甚至会在高温下提前损坏，这样更压不住温度了

@jifengg @pursuer 实际上那 b 是 binarystring ，是在没有 typedarray （ uint8array, arraybuffer ）时代的二进制 blob 替代品，你看上去是一个文本，它实际上可以存 0-255 所有的字符，不是仅限于 ascii ，也可以包含 utf-16 禁止的字符序列（反过来你即使 atob 把 utf-16 的中文 base64 结果转换为这个 binarystring 也是不能得到正确中文的）。
可以说是非常之奇妙，这玩意的构造方法就是用 String.fromCharCode ，古代的主流用法是 String.fromCharCode.apply(undefined, [1,2,3]) 来从数组里构造一整串 binarystring （用这个方法弄出来的字符串保证是 binarystring ，在一些优化过的引擎里不会用两倍空间存储）
因为过于魔法而难以进一步优化（比如一不小心就会退化成普通 string ，占用两份空间），所以 arraybuffer 才会被发明以取代 binarystring
（然后因为 arraybuffer 不能轻易扩展长度，最近又在搞 resizable arraybuffer ）

arc 并不是灵丹妙药，而且性能不一定比得上 gc 和手动内存管理，还有额外的空间占用（所有被跟踪的对象，总得有个地方来记录引用计数吧），也没“彻底”解决内存问题（比如手动 weak 可能会炸，但不写可能会漏）
性能问题举例一个最简单的地方，因为没有额外标注，arc 必然得保证线程安全性，也就是说，即使你只在一个线程中使用，也需要通过线程同步的手段去做，虽然锁的粒度很小，但是由此带来的 happens-before 的语义也会导致很多优化失效

这篇钓鱼文还真有人翻译也是笑死（
看看原文发布时间

@GeruzoniAnsasu 最后那点其实不太对（
既然都 fp 了，还用啥 this 啊🤔️，没有 this 那用啥都差不多
还不是主要为了少打几个字（

显然通过拼接 html 的形式思路就不对（
你可以考虑把数据库里的数据提取成一个数组，然后 map 成单独的组件（就像列表渲染那样
啊🤔️实际上就是列表渲染吧，只是每个元素可以是异构的而已

还不是因为主流的事件处理方式（浏览器提供的，不是你想改就能改的），要求提供一个函数做回调，这种情况下，写一个函数名意味着函数声明的位置和使用的位置就有一定距离，原地写 function 也有太长的问题
还有就是，箭头函数不会有 this 的问题，不需要外面设置一个 var self = this 这样的写法（虽然现在大家都不用 class 了，不存在 this 的问题）
虽然我觉得还是视角的问题，把回调看作延续就会比较自然了

u 盘还有非固态的吗？以前好像有那种给相机用的磁盘，挺小只的（成本极高，还容易坏，不会有人复古仿制了）
不过 u 盘主要的问题是用次品颗粒（

一般来说是一起改代码（
所以如果都是 js 的话就很合理了（
还有就是用类似 json 动态生成表单的方式，缺点是自由度比较低，但是基本上只要改后端就可以了，放在后端比较合适
剩下的我能想到的就是所谓的低代码方案，其实就相当于把前面的两个方案结合起来，动态生成，但可以容易定制
（这个容易定制当然也是有限定范围和代价的）

以前的前端开发 ide 如 frontpage 就有提供类似功能，把一个页面的一部分定义为公共组件，一改就一起改不确定底层方案是怎么实现的，我猜可能是同时修改多个文件（

说起来 bat 也是有编码问题的（
记事本默认 utf8 的话，只要系统没开实验性 utf8 ，默认保存出来的 bat 也是会炸的（有 ascii 范围外字符的情况下），反过来也是一样，开了实验性 utf8 ，那网上一大堆 bat 就用不了了
结论：不要用 bat （

主要现代前端框架不是解决怎么把页面做出来的问题，而是解决怎么在需求复杂而且经常变化的环境下，把代码的复杂性控制到一个合理的水平的问题
如果只是做出页面，并再也不需要动，那自然不需要发展这么多所谓的框架，香草 js 肯定可以解决所有问题。
问题在于，一旦需求发生了变化，比如要加一个功能，怎样才能让复杂性以低于线性的速度增长，而不是 O(n!)复杂度。

安卓返回键本来也不是返回桌面的意思（没被劫持的情况下）
而是 pop 栈中最上面那一个 activity ，如果还有前一个 activity ，那自然就会回到前一个 activity ，空了的情况下才会回到启动器

看起来很多人以为 win 本的软件成本只有 windows 授权，所以不预装 windows=可以让利给消费者
但这里有一个根本性的问题，笔记本，并不是堆砌硬件，然后就能拿来卖的，系统能安装并使用，看似非常简单，只要“安装盘一插，鼠标点点点，顶多再手动选个驱动，就可以装上”。
但这是建立在厂商花费大量精力调试软件和驱动的基础上的。如果只是单纯的硬件给你组装笔记本，可能屏幕键盘都不一定能点亮（虽然这些现在由于硬件标准化，问题少一些，但如果要考虑一些高级的功能呢？例如 win 本一直想做，但都很难做好的睡眠，休眠，现代睡眠这些功能。更不要说还有一些定制硬件如指纹识别，Windows Hello 等）。
如果目标用户只有 linux 用户，那确实是可以把调试的工作全部交给用户（实际上也不行，预装 linux 也需要最低限度的适配），但是这样的本子，销量肯定好不了；
而一旦要能让 windows 运行（包括用户自己装）起来，那这些前期适配工作也一个都少不了，windows 的 OEM 授权费在整个成本里几乎可以忽略不计，所以说，厂商给选择，实际上并没有给自己省多少成本，反而还增加了由于单独开一个 SKU 给产品生产所带来的额外开销（单独开一个 linux 产品线，或者在发货前安装系统，无论哪种方式都会有额外成本）
海外有一些可选预装 ubuntu 的本子，那也是单独给 ubuntu 做过硬件适配的，起码到手是绝对能用的状态，而不是只为了“绕过”windows oem 授权而弄一个 linux 糊弄人，这种情况下，反正两个系统都做过适配了，那成本就确实只差一个授权费了。
考虑到大多数常见本子的目标客户，单独给 linux 适配没有好处，因而推出 linux 版本没有任何意义，除了给经销商钻空子给你重装 windows （看似是好事，实际很影响品牌声誉，违法不说，经销商给 windows 里塞私货的话，消费者肯定是骂品牌方）

@monetto 从首屏最近项目里点进去应该不会开新的窗口

@bs10081 我觉得是你理解错了，我的意思是这个弹框是微软给 chrome 弹的）

用 chrome 也没用，这是最新的科技

https://i.v2ex.co/VFlt8f5K.jpeg

只是网页的话可以用这个 https://github.com/ivant04/Custom-Widget-App （有问题别问我，我不是作者）

开标准账户，然后 UAC 才会提示密码，管理员账户的 UAC 防护力度约等于纸
但是垃圾软件不一定需要管理员权限才能安装（应该多数都不需要），毕竟可以装到用户目录里（