起初学到promise的时候，对于promise的最大优势，普遍给出的解释都是解决了回调地狱问题，即主要是在写法上更加清晰简洁了，别的好像就没有了。最近我在学习异步处理这块的内容，promise、generator、thunk函数、co模块、async函数等都有涉及，期间自己实现了一个简版的promise，在学习的过程中，我感觉对promise的优势有了另外一个角度的理解。
我觉得promise最大的优势是给js提供了一个实现异步行为的合理方案和规范，是以一个对象的形式来实现（即promise对象）。借助这个对象，异步处理和回调处理是平等的，且两者不直接接触，而是都通过promise提供的接口进行交流。这种类似一个小“平台”样的机制，保证了异步处理对回调函数的使用受到了平台的限制，变得透明化、明确化了。
举个例子说明一下之前面临的回调函数被调用的过程不透明、不明确的问题。假如我们使用一个第三方库的异步工具函数，我们能做的就是把回调函数传给它，然后等待它来调用，可是工具函数最终对我们的回调函数到底是怎么用的，是调一次还是调两次，是不是有的情况下没有调用，我们都是不清楚的，也没办法控制。
针对这个问题，promise是这么做的，它内部会有三个状态，进行中、成功和失败。异步函数只能通过promise提供的resolve或reject方法，把进行中状态分别改为成功状态或者失败状态，且这两种状态一旦变化了就不能再改变，状态变化的时候会分别触发一次成功的回调函数或者失败的回调函数。也就是说promise在设计层面，就保证了回调函数只会被调用一次，异步函数内部的程序不管怎么写，它对整个处理流程的影响就只是通过改变一次promise的状态然后触发回调函数执行一次而已，之前由于异步函数不可控的行为对整体造成的影响现在被严格地限制住了。
promise基本上对异步处理环节涉及到的一些重点都做了规范化的约定，例如对错误捕获及传递，并且还提供了很多好用的工具函数，例如Promise.all、Promise.race等。有了规范化以后，好处很多，像generator和async函数在和promise搭配上，会非常的和谐。这就是因为promise是个规范化的对象，只要保证了一个异步行为是promise形式的，那拿过来就知道该怎么给它挂回调函数，或者是进行错误捕获，这对于原来的回调函数是很难做到的。generator和异步的结合，如果使用传统的回调函数形式的话，需要先整成thunk函数的形式，我觉得一方面是为了能让co模块实现自动执行流程，另一方面也是需要进行规范化。而async函数最终返回的结果还是promise，也是因为只要开发者知道了是promsie，就会知道该怎么用它，一个规范化的东西就会给人带来踏实感
