CLMan

我之前开发需要与后端通信的 Chrome 插件也遇到类似的问题，我的解决办法是买的阿里云 99 一年云服务器，在应用里面写死 IP 实现的。

犀牛书给我的观感就是太厚了，很多内容也就是科普水平，不如《高级程序设计》信噪比高，Google 了下，新版厚度减少了许多，但内在还是一样，也就是读的时候要分清哪些是干货，哪些是水，对于 JS 新手而言是个问题。

前面的批评也不是没有道理，JS 并非轻量级 Java ，虽然 JS 受到了 Java 很大影响（或者说蹭热度），比如语法风格，比如基于 UTF16 的字符串类型，对写 Java 的人来说上手很快，但原型链就足以证明它不是 Java 。

JS 的生态位就不同于 Java ，何来“可惜错过了，地盘也抢不回来了”，你为 JS 搓手顿足、懊恼，有点表演型人格发作了。

从性能来讲，JIT 加持的 JS 程序在单线程接近甚至战平 JIT 加持的 Java ，内存占用两者都比较粗狂，但 Java 是支持多线程的。不考虑生态，单纯从性能和内存占用角度来讲，对于单线程程序，选择 JS/TS 和 Java 没太大区别。

最开始是用 npm ，属于入门阶段。然后尝试了 yarn ，它的特色是`Zero-installs`，但是个人项目用不到。最后尝试了 pnpm ，被它的执行速度和 0 学习成本（对于 npm 的兼容性很好）所吸引，就停在了 pnpm 。

最近尝试了 bun ，主要是用来当作 TS 的解释器来用，也用来写一些脚本类型的项目，因为它提供的 API 比 Node.js 的 API 更加友好，冷启动速度也更快。

测试过 bun 和 node.js 在 Linux 作为自己的一个后端 JS 程序的 Runtime ，两者(JIT 暖机后)性能、内存占用基本一致，没什么差距。

"更多优秀"，但是并没有指名道姓的说出来，太敷衍了。

因为 fetch 和 超链接跳转 是两种不同的跨源网络访问，对浏览器而言，会采取不同的跨源安全访问限制策略。前者由脚本触发，后者由用户点击跳转，所以浏览器对于前者会更严。

更细节的需要爬文档： https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS 。以及多做测试，CORS 涉及到安全，不同品牌的浏览器在一些细节上存在差异，需要自己整理。

我自己修过（指替换零件、毕竟修主板还是得专业人士）、清理过几个笔记本，倒是总结出一些经验。

相变片没用过，硅脂不是越厚越好，硅脂的作用在于填补铜片与 CPU/GPU 接触面的缝隙，你只需要表面保证完全覆盖薄薄的一层，拧紧螺丝就行了。

拧散热器螺丝要讲究技巧，按照 X 的交叉方式先拧几圈固定螺丝，然后循环这样的方式，直至把所有螺丝拧紧，这样是避免硅脂不均匀分布。

现代笔记本的散热模组都是一体化的，可能散热模组老化或者你清灰过程中造成了物理破坏，最好的方式是淘宝买 2 个新的，一个替换，一个备用。

拆机前最好看下视频和教程，避免遇到坑，别自己蛮干。