引言：被神化的“现代”异步编程
在几乎所有的 JavaScript 教程中，异步编程都被描绘成一条清晰的进化路径：从回调到 Promise，再到 async/await，仿佛每一次升级都全面取代了前一种方式。这种叙事虽然易于理解，却严重歪曲了技术本质。实际上，这三种机制解决的是不同维度的难题，它们之间既有重叠也有不可替代的独特价值。一味推崇“最新最好”的现代做法，往往会让代码变得更差，而不是更好。
回调：被误解的“罪人”
回调函数是 JavaScript 中最基础的异步单位，它没有语法糖，没有刻意设计的状态模型，只是简单地在异步操作完成时执行一个函数。长期被诟病的“回调地狱”与其说是回调本身的问题，不如说是错误处理和流程控制混乱导致的。当开发者遵循单一职责、合理命名、提前返回等基本规则时，回调代码同样可以保持清晰。更重要的是，回调拥有极高的性能和极低的开销。在 Node.js 的高频 I/O 场景中，回调依然是最直接、最节省内存的方案。Promise 和 async/await 的底层最终也依赖回调，这是许多人忽略的事实。
Promise：组合与错误处理的进步，也意味着新的约束
Promise 的贡献在于将异步结果提升为“值”，从而可以被组合、映射、链式调用，并且有了统一的事件循环中的微任务顺序。它也确实消灭了嵌套金字塔。但 Promise 同时引入了热切执行（eager execution）和不可变性，使得取消变得极其困难。你无法在 Promise 创建后轻易阻止它运行，也无法在链式过程中动态修改下一步。相比回调，Promise 失去了灵活性。比如在事件监听、流处理、响应式编程中，回调依旧是最自然的选择。Promise 的“更好”是相对的，它只针对“一次异步”场景。
async/await：让并发思维退化
async/await 是 Promise 的语法糖，它让异步代码看起来像同步代码，极大地提升了可读性。但也正因如此，许多开发者开始用写同步代码的方式处理异步任务，忽略并发机制。一个典型的错误是把两个独立的异步操作分别 await，导致执行由并行退化成了串行，白白增加了等待时间。要真正发挥异步优势，必须时刻记住 await 后面的 Promise 是已经被创建并开始执行的。还有更复杂的并发控制，如限制并发数、进度反馈、背压处理，async/await 本身毫无帮助。更严重的是，滥用 async/await 会产生大量的微任务排队，可能在特殊情况下造成性能瓶颈或意外的执行顺序。
结语：重新拥抱异步的本质
回归 JavaScript 异步编程的本质，我们不应被“现代化”口号迷惑。回调适合处理连续事件和高频交互，Promise 适合一次性结果的组合，async/await 则适合简化那些顺序依赖的业务逻辑。没有哪种机制是绝对的正解，只有针对具体场景权衡后的最优解。当代开发者更需要的是理解事件循环、任务队列和并发模型，而不是盲目追逐语法潮流。学会在三种工具间自由切换，才能在真实项目中写出既高效又易维护的代码。这才是真正的“现代 JavaScript”。