@xialvjun 你 Node 啥版本，我是 v15.13.0，你换个版本试试？

你执行完脚本后用 echo $? 来看一下退出代码，如果是 0 的话就是正常退出，如果是非 0 的话就说明可能出了啥问题。

不用改 require 语法，node 是支持 ESM 的，只需要在 package.json 加上"type": "module"就可以了，当然前提是你当前的 node 版本比较新，不需要 flag 就可以直接用 ESM 。

只要能满足需求、能招聘到开发人员，为什么要换技术栈呢？
因为能招聘到，所以不换技术栈；因为有企业在招聘，所以依然有人学。

等将来浏览器不兼容 jq 了，用人单位用 jq 无法满足需求了，就会自然而然换框架。

个人可以追求新潮的技术，但对于组织单位来说新潮没意义，收益才是最重要的。

"got": "^11.8.2",
"ts-node": "^9.1.1"
测试没有问题。

你这个 try 没执行完，按理说 got 执行完后会有 console.log('got', res);输出，这个我这边测试是能输出一大串，你没有输出这个直接退出了程序，说明在执行 const res = await got('https://www.baidu.com');的时候就导致程序退出了。

不知道是 ts-node 还是 got 的 bug，你这个代码完全没有用 TS 的语法，直接 node ./index.js 就能正常运行，你试试直接用 node 运行有没有问题。

理论来说，用 TLS 只要用对算法就有一定的安全保障，参考这个 https://en.wikipedia.org/wiki/Transport_Layer_Security#cipher-table
尽可能用 TLS1.2 和 TLS1.3 。

但微软的东西我是一直都不大感在非安全区域用的，毕竟目标大，保不齐有啥 0day 漏洞被发掘利用。

很多网络协议搞加密比较麻烦，特别是内网申请证书还要设置一堆域名，自签证书用着也很反人类。

我家里是用的华硕的路由器，直接开启了自带的 OpenVPN 和 DDNS，然后所有流量都走 VPN，用了一年多了没啥问题。你要知道 VPN 是专门干这个用的，安全性和可用性都是经过验证的。

没有物理隔离没法谈安全，最坏的情况就是运营商在 VPS 的软硬件上动了手脚，那你的任何安全措施将没有意义。

除非 VPS 上仅走密文，比如 VPS 上做 TCP 转发 HTTPS 的流量，加密是在你本地的设备上进行的，解密是在远程网站服务器上进行的，VPS 仅走密文且没有解密能力。

或者障眼法，用非主流技术，让运营商看不懂来你在做啥。

不过另一个角度来看，你得评估你的隐私信息对外人来说有多高的价值，以及运营商专门做坏事的成本以及对自己品牌造成的风险（被发现后以后还做不做生意了），综合衡量得出一个运营商做坏事的几率，如果几率较高不能接受就不用，但如果几率较低可以考虑忽略风险。

@starxg 我是比较受不了虐心情节的，这个剧感觉还好。《你好再见，妈妈》倒是更虐一点。

@starxg 那个《柒个我》名字错了，这个是中国版的剧，一样的剧本，韩版的叫《杀了我治愈我》

猫鼠游戏
战争之王
阿甘正传

这剧不错，男一男二互动嗑得很开心。

韩国有好几个鬼怪题材的都很不错，《哦我的鬼神大人》《你好再见，妈妈！》

另外还有几个非鬼怪的，但比较魔幻的，比如《 W 两个世界》《柒个我》

我前几天遇到了这个问题，根据 Google 的官方的文档，进入 Play Store 的应用程序信息界面，然后清除数据，重新启动就好了。

印象里 RDP 和 VNC 都是不保证传输安全的，需要靠额外的安全传输通道来保证传输安全，比如 SSL/TLS 、SSH 、安全 VPN 。

安全都是相对的，采用什么程度的安全措施取决于你能接受多高的风险。

比如你相信内网是安全的，不会有蹭网者或者通过其他方式入侵到内网的人或程序搞事情，那么你完全可以在内网裸奔，比如全都明文传输，甚至都不设置密码。

理论上来说，你用安全 VPN 或 SSH 两者之一就能具备较好的传输安全，当然嵌套越多安全性也就越高，但相应的性能和维护成本可能就会成为主要问题。

能看到的基本上只有协议、域，这里的域是指域名+端口号，其余的就都被加密了。

在你的例子里，url 中域的部分是明文的，路径部分被加密，我举个例子：

https://baidu.com:8080/search/news?keywords=haha

这里明文的是 https 、baidu.com:8080，其他所有信息都被加密了。

干哪行都不容易。

软件开发行业的竞争可能比财务要激烈很多，那么问题来了，你打算如何在这个竞争十分激烈的行业中立足？没有破釜沉舟的觉悟的话应该也做不久。

不过作为业余爱好还挺好的，可以学个 Python 、JS 之类的，平时处理个数据、算个公式啥的还挺方便的。

买啥戏机取决于想玩什么游戏。有的游戏 PS4 不能玩，有些游戏 Switch 不能玩。所以先看看游戏，想玩啥，然后再看什么主机能玩。

越简单的语言对开发者要求越高，比如 C 、JavaScript，稍不注意就可能写出有缺陷的代码，而且这些代码中大部分是可以运行的。

可以去 benchmarksgame 看看 Rust 的压测表现，性能和 C/C++相当，到这种程度又要规避很多 C/C++常见的开发痛点，于是就设计出了一些复杂的开发模式，以至于让 Rust 的学习曲线变得陡峭。

可能习惯了就好了，特别是现在还带着很多其他语言的思维定式，比如 Rust 里的 Ownership 和 C 里的指针操作乍一看长得差不多，但实际上是完全不同的理念。

当然看代码看不懂也不一定是自己的问题，代码是有可读性好坏之分的。

作为一个大学英语四级都没过的人，原版 Book 已经看了一半了，打算看完后再看 Rust by Example，以及去 GitHub 上找找 coreutils_rs 之类的简单项目看看。

每个人对团队氛围的要求是不一样的。

很多人都不喜欢被束缚，尤其是我，所以我通常是不会用 eslint 的。

首先要明确一点：JS 是一门极其灵活的语言，一个需求可以用超多种方案来实现，但并不是所有方案都没有隐患，所以对开发者的要求很高，开发者需要有大量的经验以及良好的习惯来规避各种各样的隐患。

于是在团队协作的项目中，你会发现因为每个成员的水平不一样，并不都能驾驭好各种各样的骚操作，以及不同的编码风格可能会导致整体代码的可读性较差；
当代码问题成为阻碍产能的重要问题的时候，就需要工具来辅助：Linter

接下来是另一个共识：工具是用来解决问题的，不是用来制造问题的。

那么如何利用 ESLint 来解决团队已经遇到的问题，同时又不产生更多问题，这个不同的 Leader 可能会有不同的策略。
我的策略是做加法，即为先关闭所有规则，然后把实际代码中的问题搬到 Codereview 会上然后让团队一致同意添加相应的 lint 规则。

我会对规则进行分类：
1. 一定或在绝大多数情况下都会导致缺陷的写法。
2. 虽然不会导致缺陷，但是会较明显地影响代码的可读性。

添加每一种规则的时候，要记录有问题的代码案例，以及为什么添加这一条规则，这样新入职的员工可以参考。

最后就是，这些规则都不是一成不变的，如果随着变化使得某一条规则不再适用，可以随时讨论修改或去掉它。

没有物理隔离就没法谈安全。

所以最最最最底线是要保证你的终端设备是安全的，否则你不用 pin 用长的主密码也照样会被窃取，再加上目前主流的密码管理工具都是本地加解密模式，说不定偷解密的密码库比偷秘钥还简单。

上面分享 Windows Hello 的文章跟楼主讨论的问题其实并不是毫无关系，主要是介绍了一下 pin 的安全性思想，这个在任何产品上都是通用的，即是：pin 机制的安全性是建立在诸多限制和安全策略的前提之上的，因为有相对合理的安全性，所以可以用在一些场景中。

所以正面回答楼主的提问的话，破坏了保证 pin 机制的限制和安全策略之后，显而易见 pin 的安全性大打折扣，但与此同时，主密码的安全性也损失不少。

如果不放心，可以牺牲一些便利性换取更多的安全性；毕竟，
安全都是相对的。

人们习惯上认为 nightly 适合测试尝鲜、stable 适合生产，但其实不同的项目会因为流程、质控等差异而体现出不同的稳定性。

Rust 设计哲学之一就是可靠，所以用 Rust 写的程序可能不需要花多大功夫就能天生比 C/C++可靠很多。

另一方面生产肯定还要结合合理的开发管理制度、流程以及严格的测试来确保最终交付的质量符合预期。

任何技术选型都是要评定风险的，所以建议跟社区实际了解 Rust 的 nightly 版本的可靠性表现，然后作为风险因素来权衡选型；比如生产项目对可靠性要求极高，而 Rust 本身语言带来的可靠性综合 nightly 版本带来的不可靠性是项目可接受的，那么就用 nightly，否则就用 stable 或者其他技术选型。

越简单的语言，对开发人员要求越高。

C 很简单，但是经验不足的开发者极其容易写出有缺陷的程序，而且恐怖的是这些程序多半是可以启动运行的。

Rust 的设计目标之一就是能用一些万全策略来规避以往在 C 、C++上遇到的各种问题；如果你觉得解决这些问题并不是你的首要需求，那么你可能并不需要 Rust 。

作为一个大学英语四级都没过的人，Rust 是第一个我完全读英文教材学习的语言。