直接使用 Node API 来发起请求：
HTTP： https://nodejs.org/dist/latest-v14.x/docs/api/http.html#http_http_request_options_callback
HTTPS： https://nodejs.org/dist/latest-v14.x/docs/api/https.html#https_https_request_options_callback
入参和出参是什么 Class 的对象就看对应 Class 的文档。另外 Node 异步非阻塞以及 Callback 机制得懂。

广泛使用的第三方请求库 Axios：
https://github.com/axios/axios
得懂得 JS 的 Promise 、async/await 。

JS 基础不行的话看 MDN： https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Guide
Node 基础不行的话看 Guide，花不了多长时间： https://nodejs.org/en/docs/guides/

作为程序员英语得过关。

你可以在学会走之前先学会跑，但是总得先学会如何动腿； Node 虽然上手很简单，但是基本的特性还是得学的，API 文档还是得浏览一下的。

不积跬步，无以至千里。

让我想起了以前 QQ 空间可以自己装扮，好吧暴露年龄了。

QQ 空间上就是会有会员专属挂件，然后收一波会员费，甚至当时还催生了付费装修空间的产业。

感觉社交平台上用户会比较有折腾的动力，但如果仅仅是为了用户自己看着舒服的话，得验证一下 ROI 了。

其实现在很多 UI 框架或组件库都支持换主题，标准化足够高的话换个 CSS 文件引用就能换主题，像 Bootstrap 那样的本身也提供自定义主题编辑器，可以试着开放给用户用，再记录用户的配置。

有一个 Stylus 浏览器插件，类似于 Tampermonkey，用户可以自己写 CSS 样式覆盖特定网站的样式，也支持分享样式，如果这货普及得好的话，可能就不需要网站自己做自定义样式了。

记得之前看过一个故事，说某国总统大选的时候，一个竞选者的团队在社交网络投放竞选广告：让支持这个人的选民以为这个人还在当选与不当选的节骨眼上；让反对这个人的选民以为这个人已经毫无当选的希望。结果支持者们比以往更加发力于为这个人拉票，而反对者们放松了反对；最终因为很多中立者投了这个人，于是这个人当选了。

理论上来讲，由于获取到的信息不对等，资讯平台的个性化推荐，有可能让用户以为这就是整个世界的样子，加重人们观点的极端分化。

网上经常遇到，一个人觉得 A 是普遍的观点，另一个人觉得 B 是普遍的观点，于是两个人都认为对方的观点很奇葩。

不过也没必要妖魔化这种技术，毕竟社会是有一定的平衡能力的。

我 2015 年用了一款酷冷至尊的 240 一体水冷，至今也一直没有进行过什么维护（没加过水，也没换过零件），期间搬过三次家，也给 CPU 换过几次硅脂，现在看管子接头处有轻微水痕，不过没有发生真正意义上有破坏性的漏水，制冷效果也问题不大。

现在一体水冷做工上比 2015 年成熟多了，有的品牌也会有几年内漏水赔偿的保障，而且只要是经过严格质检的大牌水冷可靠性肯定要比自己 DIY 的分体水冷要好。

风冷的优势是可靠性相对较好、噪音小；劣势是散热天花板较低、CPU 附近占用空间可能较大。
水冷的优劣势和风冷相反。

在风道合理，以及散热器热管、散热片面积、风扇风力等足够，以及不（狠）超频的情况下，风冷压高端 CPU 没有问题。

一般来讲(当然还是得自己多看测评数据，以及考虑自己装机的实际情况)：
静音性：风冷>分体水冷>一体水冷
散热极限：分体水冷>一体水冷>风冷
空间利用率：一体水冷>风冷>分体水冷
（这块肯定都有特例，不用杠）

如果用特别紧凑的机箱的话，CPU 位置附近空间不够，那么基本上就只能选一体水冷了。
如果是空间比较充裕的机箱的话，用任何散热方案都可以。

@elfive 我上周用上了 Lyra Trio，AiMesh 走有线，然后每个节点都是双频，信号满格，无缝切换，目前没有发现任何问题。

发一封邮件，把问题指出，通常就可以了。

我之前是博客文章被一些资讯网站自动转载，我给他们发邮件之后他们就都把文章撤掉了。

我们公司一个妹子之前就说她热爱运动，但是讨厌流汗，于是她经常去游泳。

阿里云的话用可以用堡垒机+双因子认证，双因子认证可以保障账号不会被盗用，堡垒机除了能抵御攻击以外，还能对你的操作进行录像和记录，便于事后确定锅给谁。

如果强制要求必须去办公室的话，可以申请加班费、打车补、餐补。

我觉得多数人都不会认为真诚的态度是一种掉价的表现，你不用想太多，因为很可能人家根本没有把这件事放在心上。
如果你面试的是技术岗位，那么正常情况下应该优先考虑你的技术能力，而不是你的交际能力。

可视化编程门槛可能更低，看不懂字的小孩都能编程序，了解一下 Scratch 。

“开源”是个很大的课题，首先你得确定你是哪一种“开源”。当前的开源，从目的上分为几种：
1. Just for fun 。我觉得这个东西很酷，不管有没有回报，我都希望把这个东西做下去，让有需求或同样欣赏这个东西的人都可以用上这个东西。
2. 赚钱。我希望把在做的开源项目作为自己的部分或全部的收入来源。
3. Star （双关）。像写博客一样，我希望通过开源项目能提高我自身的社会声望，能够实现自我认可，或仅仅是在求职的时候作为自身优势。
4. 工作 KPI 要求。

如果是第 1 种的话，简单来讲就是“道不同不相为谋”，在适当的曝光之后，欣赏的人自然会进入你的社区，不欣赏的人也不必强求。但如果你的项目本身决定了受众群体就很窄，那么也就不要期望能够变得多么火爆，没办法也没必要。
如果是第 2 种，那么这本身就是一个商业行为了，你得像真正的商业项目一样，有盈利模式和营销策略，即便不是直接卖代码或卖程序。举个例子，虽然 Google 开源了 Android，但是深度绑定的 Google framework 是可以赚钱的；虽然 Google 开源了 Chromium，但是伴随的广告业务以及 DRM 技术是封闭且赚钱的。
如果是第 3 种，就和经营艺人差不多了，你得研究大众口味，得寻找合适的曝光机会，要尝试制造时事热点。
第 4 种，我也不清楚该怎么办，找找刷数据的渠道？

国内很多开发者并不真正了解“开源”，以为只要公开了源代码就算是开源，但实际上从上个世纪九十年代的自由软件运动开始，开源社区的发展可行性是有一整套的理论，仅仅公开源代码是不够的，现今的凡是可是续发展的开源社区都有相当专业的团队在进行管理和经营，有些公司和基金会会专门招聘开源项目经理，这也说明开源项目管理已经成为了软件项目管理的一个特定的子领域。

MAC 地址的问题很多人都已经指出了，在你的场景下不可行。

因为做限制不仅仅先于在 IP 层面做，所以建议楼主把实际遇到的问题说一下，为什么要进行限制，不限制会出什么问题，然后大家可以根据实际问题来提供合适的解决方案。

我能想到的原因可能是两种：
1. 安全性考虑，需要确保仅可信的人能够访问。这块最简单的方法是用 VPN，用户必须提供账号、密码或秘钥来链接 VPN 网络，然后网站配置仅对 VPN 网段开放。高阶一些的就是可以参考零信任模型。
2. 风控考虑，避免遭受 DDOS 攻击。这个可以通过使用一些可以防 DDOS 的 Web 应用防火墙或者想 V2EX 正在用的这种 CDN 来实现，自己在网站功能上不需要做任何调整。

招聘前要确定所招聘的职位画像，不同岗位在不同时期上需要的人是不一样的，高能力的人往往薪资要求高，那么在业务项目、团队搭配、预算等方面上是要综合衡量的。
比如某一个业务方向需要技术专家来攻克难题，那就一定得招在这个业务方向比当前所有人水平都高的人；但如果是成熟的流水线生产场景，肯定是在能力达到基本要求的同时以低薪资作为首要考虑因素的。

技术水平只是招聘参考的一个方面，很多时候还要综合考虑沟通能力、执行力、逻辑思维、行业经验、与现有团队成员的性格契合或互补等等。

@elfive 或许可以用网线连 AC AP，然后 AP 就可以双频了吧，要是想不用网线还是得选专门的 Mesh 方案吧。