在阅读了数十篇关于 es6 Promise 有多伟大以及为什么我们应该实现它们的文章之后，我有这样的感觉：ALL我的（不平凡的）JavaScript 函数应该是 Promise。
事实上，使用它们编写代码时我感觉很棒，因为我避免了厄运三角，并且似乎得到了清晰简洁的代码。 （它确实使执行的推理变得更加简单）。
我没能找到的是：你什么时候NOT使用承诺？我什么时候避免使用它们？
Update:
虽然我已经看到了一些很棒的观点，比如 API 一致性，但我还没有找到一个可靠的 NO 案例。 Lux 的回答表明，获取事件发射器的操作应该避免它们，因为重复回调与承诺不兼容。然而，我确实觉得现在的答案仍然缺乏实质内容来检查它（是否正确）。
一些经验法则：
-
当您的方法可以同步（简单的数据转换）时，请在该方法中使用同步代码。
但是如果该方法可以是同步的有时，和异步有时（基于内部或外部状态的多个代码路径），它应该是异步的always。否则，您的代码在复杂场景中的行为可能会遇到意想不到的细微差异，因此最好避免混合这两种态度。
[编辑] 正如评论中所述，当您的方法现在是同步的，但您坚信它可能需要在将来的某个时刻执行异步工作时，您可能希望从一开始就使用 Promise 以避免代价高昂的重构。
一般来说，你的 API 应该是一致的，所以最好要么到处使用 Promise，要么到处使用回调。这将使推理代码变得更加容易。
如果您正在编写超高性能代码和/或需要低内存占用，您可以考虑不使用 Promise 而是使用回调，或者使用注重性能的 Promise 库，例如bluebird https://github.com/petkaantonov/bluebird，而不是原生 Promise 实现/一般用例 polyfill。
[编辑] 不管怎样，网络平台的新功能，比如全球fetch https://developer.mozilla.org/en-US/docs/Web/API/GlobalFetch/fetch函数，返回一个Promise，并且似乎在不久的将来，越来越多的浏览器内置程序将按承诺运行。因此，如果您愿意编写现代代码，您就不会逃避承诺。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
