Node.js 官方有 crypto module，基本上就是字符串转 Buffer，然后加密和散列，很方便，可以直接用。

https://nodejs.org/api/crypto.html

密码验证的原理根本上是碰撞，即你输入的密码（最终处理成的数据），和设置的密码（最终处理成的数据）一致，则认为验证通过。所以“可逆”并不是一个必须条件，除非你有其他的用途需要加密后的密文还能直接还原成原文。

因为加密算法是要在原有数据上“加”密，所以加密后的密文的大小一定是大于等于原文的，你也可以使用压缩算法，比如你加密后的密文是 0-9、a-f，36 进制，然后你可以把它映射成 0-9、a-f、A-F、~!@#$%^&*()_+`-={}[]:;"'<,>.?/|\这些，94 进制，这样你的密文可以无损缩短长度，由于无损压缩，所以可以完美还原，但也还是有限的，如果你的原文中有不可控长度的变量，比如网站域名，有 t.cn 这种的，也有 http://www.thisisthelongesteuropeandomainnameallovertheworldandnowitismine.eu/ 这样的，由于这种不可控性使得最终加密出来的密文的长度也是不可控的。

点子不错，不过会不会不同网站对密码格式的限制条件不同呢？
比如有的网站必须包含数字、字母小写、字母大写，但不支持符号；
有的网站要求必须包含数字、字母小写、字母大写、符号；
有的网站要求符号必须多于 3 个；
有的网站要求同一个字符在密码中不能出现超过 4 次……

这样你的算法要根据不同网站对密码格式的要求切换不同模式。

鉴于理财产品通常都不是随用随取，所以建议银行卡里留几万现金，以便应急。

看你理财的目的，百万以下基本就不用考虑通过理财来赚钱了，保值顺便贴补一点通勤费用或餐费什么的会比较现实，可以考虑各大投资平台的“稳健”投资项目，一般年化利率超过 4%且过去时间比较稳定的就很好了。

钱多了又不需要攒钱买房之类的，可以划分出一定比例的资产用作风险高一些的投资，推荐不超过 30%。

理财有风险，投资需谨慎，特别是不要看见点红利就把所有财产都投了，以及不要在一棵树上吊死，多个平台均匀着投，出了风险也不至于直接破产。

看是否存在用 Array.prototype.includes，Array.prototype.indexOf 适用于真的想知道找到的东西的 index 的时候用。
相应的，想找一下数组中有没有一个值，如果有就取出来，用 Array.prototype.find

在 MDN 上刷一刷 Array 都有哪些方法，会发现 JS 好贴心，好多功能都有现成的了。。。

已 Block 那位键盘侠。。。

私以为权利和义务是分开的，发现问题即时通知相关负责人员，尽了应尽的义务，这是值得鼓励的的事情。
对方负责人有决定是否处理的自由，不越俎代庖，以示尊重。
一方面仁至义尽即可，另一方面明哲保身。

但如果自己和公司利益绑定，如果对方选择不处理，还是找对方领导推进一下事情的解决吧，总比出险了自己跟着遭殃要好。
还记得曾经全球第一大的赛门铁克 CA，因为签发不合规的信息安全问题导致一年内直接死翘翘。

这个应该是 JS 版的 Brainfuck 解释器？

我还以为是这个：
https://github.com/alcuadrado/hieroglyphy
这个可以把任何数字或字符串转换成 Brianfuck 风格的 JS 原生代码。

因为 A 必须依赖 B 执行完才可以继续执行，同时 B 也依赖 C 执行完才能继续执行，所以不管你用 callback 还是 Promise 还是 async，都逃不掉三者都做同步化处理：

callback 版本：

function A(resultFromB) {
let someData = resultFromB;
return someResult;
}

function B(resultFromC, cb) {
let someData = resultFromC;

//Some logic code
cb(someResult);
}

function C(cb) {
(new Promise()).then((result) => {
cb(result, A);
});
}

C(B);

Promise 版本：

function A(resultFromA) {
let someData = resultFromA;

return someData;
}

function B(resutlFromC) {
let someData = resutlFromC;

//Some logic code
return someResult;
}

function C() {
return new Promise();
}

C.then(B).then(A).then((resultFromA) => {
//Do something.
});

避免不了的，但是外层层都用 async 不是因为内层用了 async，而是因为外层关心内层执行完的结果，如果不关心的话完全可以不用 async。

function B() {
new Promise();
}

function A() {
B();//我不关心 B 执行完返回啥，就让他自生自灭吧
//继续执行其他的代码
}

A();

@azh7138m 你开心就好

@azh7138m

我看不大懂你写的。。。
你的第一个代码，api 函数执行如果是异步过程的话，你的 try 永远捕捉不到任东西。
第二个的问题不是在于 rpc 是不是用 Promise 实现，而是 urls 暴漏在那么广的作用域下会有风险（让然代码逻辑处理好也是可以没问题的），把 urls 封装在 Promise 里，通过每一级的.then 向下传播，中间不可能被外界作用域的程序篡改：

```
let urls = {};

let theP = new Promise((res, rej) => {
let urls = {};
res(urls);
}).then(urls => {
urls["domain 点 com"] = 3;
return urls;
});
urls["domain 点 com"] = 2;
theP.then(urls => {
console.log(urls["domain 点 com"]);
});
```

这里边有两个 urls，但是 Promise 能保证调用链中传递的 urls 不受外部作用域的 urls 的操作影响。

上面说的都不是绝对的，得看实际情况。

bable 可以根据需求转换语法，最著名的是把 ES6+转换成纯 ES5，最早 core.js 部分就包含 Promise 的 polyfill 了，只不过现在很多人不需要那么苛刻要求转成 ES5。
去看一下 @babel/polyfill 文档吧。

@azh7138m 可靠性的体现是：

//Promise 的错误捕捉机制
(new Promise((res, rej) => {
haha;//这里因为找不到"haha"是什么，所以会报一个错
}
)).catch((error) => {
console.log('捕捉到错误了');
return [];
}).then((result)=>{
console.log(`得到的数组的长度为${result.length}`);
});

//一般值传递回调函数的错误捕捉机制
function cb1(cb) {
let result;
try {
result = Math.random();//这里假设做了某种操作，我用 Math.random()来举例
} catch (error) {
cb(error);
}
haha;//这里因为找不到"haha"是什么，所以会报一个错
cb(null, result);
}

function cb2(error, result) {
if (error) {
console.error(error);
} else {
console.log(result);
}
}

cb1(cb2);

Promise 内部有任何问题，包括语法问题，都可以通过后边挂载的 catch 回调捕捉到；但 callback 不一样，得自己在自己觉得可能会有问题的地方加 try/catch，如果 try 没有覆盖到出错误的点，就可能会造成整个程序崩溃。相比来说，因为 Promise 的错误捕捉机制用起来更加简洁、覆盖面更广，所以反映在规模性的项目上可能可靠性更好。你也可以抬杠说在回调函数里每次都全局 try，但相比 Promise 来说要多写一点代码吧，而且看起来也不如 Promise 那么言简意赅。

作用域混乱我是特指的是楼主博客里的一个用法：

let urls = {};

function rpc (url, callback) {
if (urls[url]) {
return callback(urls[url]);
}
request(url, (err, res) => {
urls[url] = res;
callback(err, res);
});
}

urls['domain.com']=3;

oo();//这里可能是手误修改了 urls

rpc('domain.com',console.log);

function oo() {
urls['domain.com'] = 2;
}


这里 urls 暴露在一个相对宽广的的作用域下，如果在调用 rpc 之前还有其他的代码执行，则有可能会有意无意地修改 urls 的值，有意的还好，无意的就会产生逻辑 BUG 了。

以上都是针对一些实际情况举的例子，不是为了说明 Promise 一定就比 callback 好用，而是说明 Promise 能解决一些以往使用 callback 的痛点，实际上 Promise、Generator、Async/Await 都是语法糖，都是可以用 callback 实现的（要不然 babel 就不存在了），应用语法糖在特定情况下用可以事半功倍，但如果有的地方你觉得用 callback 最合适，也没必要非要赶着上 Promise。

@azh7138m 不是 callback 和 Promise 的本质上的区别，因为 callback 其实也是可以逐级传递错误信息的，只不过用 callback 可以有多重实现方案，而 Promise 只提供了唯一方案，相比来说 Promise 更标准更可靠，标准化的好处就是任何第三方包都遵循标准任何人都可以直接使用，不会遇到错误传递方案不同导致的不兼容。

楼主举得例子不恰，外部放置临时变量来记录异步操作是否成功的方法只是 callback 传递状态的众多办法中的一种，而且可能是最差且几乎没人用的方法，这个方法有很多弊端，比如作用域混乱导致的调试成本太高，以及可读性差等，callback 在调用链上做状态传递是能规避这个方案带来的很多问题的，比较起来，Promise 是用统一标准方案来实现的状态传递，兼容性有保障。

只订阅了几个人，要么就是看鬼畜和番剧，再不济就是定向搜索按排名看，接触不到营销类的内容。

有文件改动监听的功能得注意一下，watch 和 git 的追踪功能都是用操作系统的 API 实现的，wsl 和 win 还是两个操作系统，各自有各自的 API 来实现监听文件修改的功能，又因为 wsl 运行于 win 之上，所以 wsl 内修改文件的时候 win 是知道的，但 win 修改文件 wsl 是无法知道的。

@FakeLeung

亲测。

风扇噪音普遍大，
非专业银幕效果差（分辨率），
白天或开灯状态下对比度难比电视差很多，
对焦神烦，
贵。

不过对于租房的人来说还是比买电视搬家方便。

node 是异步非阻塞机制，所以请求不会排队。通常数据库操作需要加锁。

其实也可以不加锁。可以单独开一个表做计数器，抽奖抽到先更新计数器加 1，看更新后返回的结果，如果数量未超就记录中奖者，如果数量超了就变成未抽到。

什么类型的纯音乐呢？

古典？ new age 代表的轻音乐、jazz ……我个人是在听史诗，比如 x-ray dog、epic score、audio machine。

加密算法都是可逆的，因为加密最终还是要解密的，否则就是摘要或有损压缩。
同一个密钥就可以完成的加解密通常是对称加密，当然私钥能推导出公钥的非对称加密也可以。去维基上搜一下对称加密算法都有什么就知道了。
另外经典密码学里也有一些可以用的，比如凯撒密码（ rot13 甚至连加解密算法都是一样的），以及密码表。

@huclengyue 我只跑了个 terminator，没问题，个人感觉性能上不如虚拟机，如果你的 win 硬件还不错的话性能应该能忍。

我没成功启动 gnome，能折腾的话可以研究一下。启动一个 terminal emulator ＋一个 IDE 估计是 OK 的。