@
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。