好的代码是能让人读出智慧的，不是单纯遵循某种硬规则的。

沟通的时候要讲究控制信息密度，信息太少无法准确传达，信息太多又难以让人提炼需要的部分，代码注释也一样。

找运营商报修试试，不要说是路由器问题，就说腾讯会议会提示网络不佳，怀疑他们网络有问题，让他们来检修一下。

云服务器外包了机房运维服务（硬件方面）、电费、网络，特别一些网络是 BGP 的；在家里部署的话，前面这些都需要自己提供。

主要还是看需求，像 NAS 这种很可能被带宽卡脖子的放家里可能会比较合适，毕竟云计算的带宽通常比较贵；像网站可能云服务器省事一些，静态网站也可以放家里然后套个 CDN ；像游戏私服可能 BGP 网络连通性好一些……

有个简单办法，就是买个那种测功率的插座，然后用自家电脑测一下，家用 CPU 有睿频之类的技术负载不高的话平均功率也低一些。

另外如果是 NAS 的话，耗电大户往往是机械硬盘。

@afeiche #7 编译 addon 的时候可能会依赖一些 C/C++的库，这些库可以用操作系统的包管理器安装，也可以手动安装到正确的位置，甚至自己编译。

正常情况下，module 的编译问题，其开发者应该都会妥善解决，你执行 npm install 的时候至多会出现库不存在需要自己在系统环境中安装，这个去 Google 一下应该也不难。

但毕竟这块耦合了 C/C++技术栈，说不准会出现一些开发者没有妥善解决的问题，而这些问题通常 Node 应用开发者又解决不了。

如果不得不用 Addon 的话，建议尽量使用知名的、成熟的，有问题也可以去翻翻 Issue 或自己提一个 Issue 。

@hronro #5 WASM 、C/C++ Addons 、N-API 在不同场景下表现的性能也不大一样，不同的编译器、不同的 Node 版本也都会有差异，生产上也需要参考特定场景下的压测数据才能做决策。

WD-40 是个牌子，有很多款产品，比如大家常用来修 Switch 手柄的除锈润滑剂、精密电器清洁剂，还有机械润滑油之类的。

我前段时间买了一小瓶润滑油，专门用户门轴润滑的，这东西如果想起到一定时间润滑的效果，肯定挥发不能太快，喷的时候在通风的地方喷，然后晾上几个小时，应该就问题不大了。

在公司负责风控，感觉可能需要多考虑如何避免被滥用，比如短信轰炸平台。

题主的方案是可以的，我们以前用过这种方案，前提是编译环境和生产环境的硬件架构、系统、依赖包、Node 版本等都一致，或者很明确是兼容的。

当然现在来说，容器可以解决除硬件环境以外的其他所有问题，更方便一些。

自己可以按照需求选购，不需要智能就买普通的，或者带智能但不用智能那一部分，以你需要的那一部分功能作为价格的参考标准，强塞“智能”又贵的肯定就因性价比低被筛掉了。

洗衣机智能有一定的需求场景，比如家里人早出晚归，白天没人，就可以出门前把衣服和洗涤剂放进去，定时或到时间远程控制启动，等回到家洗完了。至少我自己之前一直是这样用的。

不过确实一些功能简单的小家电加块屏幕、连个 Wifi 蓝牙就说自己是“智能”的，大多场景下确实没必要，作为消费者可以用钱包投票，让市场证明有些产品是失败的。

技术上来说，可以。

就像银行里有很多人的存款，那么银行是否可以私自把客户的存款转移给别人；运营商自身是否有安全管理；运营商内要想查看客户的短信记录和内容，需要哪些授权，是否有审计。

https://262.ecma-international.org/5.1/#sec-7.9

官方文档里面说明了自动补充分号的思路，你需要在省略分号的同时，确保代码不会产生歧义，自己做的话可能会有些心智负担，除非你用 StandardJS （注意这只是个工具名称，并不真的是 JS 的 Standard ）之类的 Linter ，可以帮你自动规避不写分号会产生歧义的情况。

但我个人推荐能写分号的地方都写分号，特别是可能会涉及到代码 minification 的情况，你源代码执行的时候可能自动补充分号是正常的，但 minify 之后很可能就会出现问题。

分号的存在就是为了避免歧义的情况，因为 JS 不靠缩进和换行来表示表达式的终止或层级关系，有些情况下无法避免写分号，刻意不写分号的意义就不那么大了。

@an168bang521 #34 不是律师，仅提供一些个人了解的情况：
1. License 原文没有说以什么方式被包含到再分发副本中，也就是说这个是比较灵活的，License 全文贴上肯定最稳妥，目前也见过很多软件是采用链接的形式，所以你把 License 原文的链接包含到你的文章中，应该是可以的。

2. 按 License 的要求，需要包含 License 副本，但并没有规定如何包含这个副本（仅针对 MIT ），比如你可以配置打包工具，把 License 保留或加回去，也可以在网站某个地方提供一个 License 清单。

国内技术发展特点跟国外各地区可能不大一样。

国内开发者的技术资讯获取渠道比较集中，一门技术如果宣传到位的话，在国内会以极快的速度传播，特别是那些有科技巨头背书的技术。
国内开发者普遍有技术焦虑，生怕自己当前所用的技术会很快被淘汰，出于自保会比较愿意学习和使用时下热门的技术，特别是很多技术的宣传都是捧一踩一，以及各种“取代论”，这种焦虑会更加强烈。
国内开发者普遍有“面向简历开发”的意识，有头部公司在使用一门新技术的话，开发者们更愿意在自己的简历中能对这种新技术有所体现。

Go 就是顺应国内的这种技术发展特点，才得以在国内变得非常热门。

因为这些特点，很多技术在国内比在国外会更早进入 Hype Cycle 的过高期望的峰值。两年前 ThoughtWorks 技术雷达也明确表示，过去技术会先在欧美地区流行，然后才进入中国，但如今反了过来，技术很可能会先在中国流行起来，然后再在世界其他地区流行起来。

其他语言难以像 Go 这样贴合国内技术发展的特点，比如宣传不到位、没有科技巨头背书或者只是单纯打不过 Go 。
但除了语言之外，很多技术在国内有着类似 Go 的发展现象，比如 Vue 、PG 、K8s ，以及 Rust 也有这个趋势（但可能不在 Web 服务领域）。

海外各地区技术会更加多样化一些，如今海外 Web 开发领域依然不乏 Python 、Ruby 和 PHP ，在国内这三种语言已经很难在 Web 开发领域找到工作了。

私以为，结婚最起码满足两个条件：
1. 两个人三观基本一致，或互相兼容；
2. 两个人有默契，知道对方会对什么行为有什么反应。

从题主描述来看，两个条件可能都不满足。

AUR 是个神器。
WSL2 里跑 Arch ，可以试一下。

我在 WSL2 中跑 idea 做 Web 全栈开发，感兴趣可以参考我这个教程 https://github.com/libook/WSL-GUI

一个绕不开的需求就是实名制。

短信可以同时满足实名制和二次验证，且用户使用成本低，用户不会觉得麻烦而流失，确保后续可以让更多用户付费。

实际上运营商现在搞了一种更快捷方便的验证模式，连短信都不需要，只需要用户点一下按钮，运营商通过底层技术来确保认证有效。

你在服务器上有执行 npm install 吗？
错误写得比较清晰，说找不到 Buffer 或找不到 Buffer 的类型定义，那么极有可能是你服务器上没有安装 @type/node 包，这个包就是包含 Node 的所有 API 的类型定义文件给 TS 编译器用的。

想学的话还是建议从纯 JS 的 Node 开始，理解了 Node 的工作原理之后再考虑引入 TS ，这样循序渐进，毕竟 TS 不是只为 Node 提供的，Node 也不一定非要用 TS 。

Node 的官方文档有 Guides ，也写得挺清晰的，看英文不方便也可以找中文翻译版，看完也花不了太多时间。

@mikulch #12 我个人不大喜欢 TS ，平时也用得少，我更喜欢纯 JS+JSDoc ，写得够规范、IDE 够智能的话也可以完成 TS 那样的类型检查。如果用纯 JS 写的话，不用第三方 modules 甚至 0 配置文件就可以写个服务，比如我手写过一个 Gitlab 的 hook 服务，就一个 js 文件，直接 node 指令运行就可以了。

凡使用工具就一定会有收益和成本，对于 TS 来说，类型检查是收益，而配置麻烦就是成本，但好在企业生产中大多项目只需要配置一次，而且绝大多配置都可以通过 git 传递给其他协作者。

工具是用来解决问题的，不是用来引入更多麻烦的，按需要使用，没需求就没必要硬上。

除了技术解决以外，还可以 12321 投诉，现在主流应用都要求开屏广告必须提供容易点按的按钮跳过。

个人印象里卡西欧的机械方面好一些，雅马哈音质好一些。

我家里有一台卡西欧电子琴，撑了 20 年；前几年买新琴，两个牌子也挑了挑，感觉个人比较喜欢雅马哈的音色，就买了个雅马哈。

当然不同型号也会有差异。

电钢太贵了，还占地方，如果不是天天练或对触感有要求的话没必要，业余向玩一玩电子琴也 OK 的。