MDN老式异步回调示例内层函数为何接收上层参数及代码优劣对比

问题1：参数传递逻辑与示例省略实现的原因 #

• 为什么需要把上层函数的参数传入内层：
  本质是异步流程的串行依赖导致的：整个吃披萨的步骤是一环扣一环的，你得先选好配料才能下单，下单拿到订单号才能取餐，取到披萨才能吃。而这类老式回调异步函数的执行结果不会直接return出来，只会在异步操作完成后当成参数传给回调，所以下一个步骤的函数必须拿到上一步的结果作为入参才能正常跑，不然连要处理的业务数据都没有。
• 为什么示例没给每个函数的内部实现：
  这个示例的核心是用来展示回调嵌套（也就是「回调地狱」）的糟糕代码结构，内部实现和要演示的核心问题无关，而且不同场景下这些函数的实现差异极大，比如chooseToppings可能是读用户在页面勾选的选项，也可能是拉取后端存的用户偏好，写出来反而冗余，干扰大家看嵌套的核心结构，所以就省略了。

问题2：修改后的代码是否更优 #

这版修改完全不是更优，甚至是跑不通的错误代码：
placeOrder 这个函数本身就必须接收配料参数才能生成有效订单，你把toppings入参删掉之后，它根本不知道你要给披萨加什么料，怎么可能下单成功？
就算你在注释的//some work with toppings位置把toppings存成全局变量或者上层作用域的变量，绕开了传参的问题，那也是更差的写法：平白多了不必要的共享状态，代码可维护性、可测试性都会降一大截，还容易出现变量冲突的bug。

内容的提问来源于stack exchange，提问作者kankan256