一、参数定位：回调函数的角色与边界
.then() 接收的两个参数本质上是状态处理器，分别对应 Promise 的两种终结状态。它们的定位需从三个层面理解：
1.1 状态专属处理器
onFulfilled 仅在 Promise 成功（fulfilled）时触发，接收成功值作为参数；onRejected 仅在失败（rejected）时触发，接收失败原因。这种严格的状态隔离避免了条件判断的冗余，但要求开发者明确区分业务逻辑的成功与失败路径。
1.2 异步执行的契约
无论 Promise 何时完成，两个回调始终通过微任务队列异步执行。即使对已完成的 Promise 追加 .then()，其回调也会延迟到当前同步代码结束后触发。这种设计保证了主流程的连贯性，却也容易引发对执行时序的误解。
1.3 链式调用的枢纽
每个 .then() 返回新 Promise，其状态由回调的返回值决定：
- 返回普通值：生成成功状态的 Promise
- 抛出异常或返回拒绝值：生成失败状态的 Promise
- 返回 Promise 对象：等待其完成并透传状态
这种隐式转换机制使链式调用能够无缝衔接同步与异步操作，但要求开发者精准控制返回值类型。
二、执行逻辑：状态变更后的触发规则
回调函数的执行遵循严格的时序与状态规则，其核心逻辑可分解为三个阶段：
2.1 状态锁定与队列管理
当 Promise 状态从 pending 变更后，所有关联的回调会被加入微任务队列。此时即使再次修改状态（理论上不可行，因状态不可逆），新回调也会等待下一次状态变更。这种机制确保了回调总能获取最终状态。
2.2 微任务与事件循环的交互
回调的执行优先级高于宏任务（如定时器），但低于当前同步代码。在事件循环中，微任务会在每个宏任务阶段结束后集中处理，直到队列清空。这种特性使得多个快速完成的 Promise 回调能够按顺序执行，而非并发处理。
2.3 延迟调用的实际影响
考虑以下场景：一个已完成的 Promise 立即调用 .then()，其回调仍会延迟执行。例如，在用户交互事件中追加异步处理，需注意回调可能无法立即响应业务需求。此时可通过显式同步标记或状态管理来协调时序。
三、数据流控制：值与原因的传递机制
回调函数的参数传递是 Promise 链的核心功能，其规则决定了数据如何在异步流程中流动：
3.1 成功值的传递链
onFulfilled 接收的成功值会沿链向下传递，传递规则包括：
- 直接透传：若回调无返回值，下一个
onFulfilled会接收当前成功值 - 值转换：若回调返回新值，下一个
onFulfilled会接收转换后的值 - Promise 解包：若回调返回 Promise，会等待其完成并透传最终值
这种机制使得数据能够在异步流程中逐步加工，而无需显式管理中间状态。
3.2 失败原因的捕获与转换
onRejected 接收的失败原因可通过三种方式影响后续流程：
- 静默吸收：若回调无返回值或返回普通值，错误会被视为已处理，后续链接收成功状态
- 错误转换：若回调返回成功值或 Promise，可将错误状态转为成功状态
- 错误透传：若回调抛出异常或返回拒绝值，错误会继续向下传递
这种灵活性允许开发者根据业务需求选择错误处理策略，但也易因疏忽导致错误被忽略。
3.3 隐式状态转换的陷阱
回调的返回值类型会隐式决定后续 Promise 的状态。例如：
- 返回
null或undefined会生成成功状态的 Promise - 抛出字符串错误会生成拒绝状态的 Promise
- 返回已拒绝的 Promise 会透传拒绝状态
若未明确理解这些规则，可能导致链式调用意外中断或状态错误。
四、典型错误模式与修正方案
4.1 错误处理链断裂
问题表现：链中某环节的错误未被捕获，导致后续逻辑静默失败。
根本原因：省略了 onRejected 或未使用 .catch()。
修正策略：
- 在链末尾显式添加
.catch() - 在每个
.then()中同时提供onRejected - 使用混合模式：部分环节用
.then()的onRejected，末尾用.catch()
4.2 异步时序误解
问题表现：在同步代码中依赖异步回调的即时性，导致数据不一致。
根本原因：忽视微任务队列的延迟执行特性。
修正策略：
- 避免在同步代码中直接读取异步回调的修改
- 通过额外状态标记或事件通知协调时序
- 使用
async/await语法简化时序控制
4.3 返回值类型混淆
问题表现：意外返回 Promise 导致流程中断，或返回普通值导致错误被忽略。
根本原因：未明确区分同步返回值与异步返回值。
修正策略：
- 在需要等待异步结果的环节返回 Promise
- 在错误处理环节确保返回非拒绝值以终止错误传递
- 使用类型检查工具验证返回值类型
五、高级应用模式
5.1 条件分支实现
通过 onFulfilled 和 onRejected 的返回值，可构建复杂的条件逻辑。例如，根据数据有效性决定后续流程：
- 成功时返回加工后的数据
- 失败时返回默认值或触发恢复机制
5.2 并行操作协调
结合集合方法（如 Promise.all()）时，可通过 onRejected 处理部分失败：
- 统一捕获所有操作的错误
- 根据部分成功结果调整业务逻辑
- 实现“部分成功”场景的降级处理
5.3 资源生命周期管理
在 onRejected 中实现资源释放逻辑，确保异常情况下资源不被泄漏。例如：
- 数据库连接在操作失败时关闭
- 文件句柄在写入失败时释放
- 网络请求在超时时终止
六、与其他方法的协同
6.1 与 .catch() 的互补关系
.catch(onRejected) 是 .then(null, onRejected) 的语法糖，但更推荐使用 .catch() 以避免以下问题：
- 嵌套
.then()时，第二个onRejected无法捕获第一个onFulfilled的错误 - 链式调用中，
.catch()可集中处理多个环节的错误
6.2 与 .finally() 的配合
.finally() 适用于无论成功或失败均需执行的逻辑（如日志记录、状态重置）。其回调不接收参数，且需返回可等待对象以避免中断流程。
6.3 与 async/await 的互操作
在 async 函数中，.then() 的链式逻辑可转化为 try/catch 块。两种风格的对比：
- Promise 链：适合线性异步流程，显式表达数据流
- async/await：适合复杂逻辑，通过同步语法简化异步控制
实际开发中，可根据场景选择或混合使用两种风格。
七、总结与关键实践
- 明确参数角色：
onFulfilled处理成功路径，onRejected处理失败路径，避免混用逻辑。 - 控制数据流：通过返回值类型精确决定后续状态，防止意外状态转换。
- 完善错误处理：采用结构化错误处理，确保错误不被静默忽略。
- 协调执行时序：理解微任务队列的延迟特性，避免同步代码依赖异步结果。
- 选择协同模式：根据场景灵活组合
.then()、.catch()、.finally()和 async/await。
掌握这些核心机制后，开发者能够构建出既健壮又灵活的异步流程，有效应对复杂业务场景的需求。在实际项目中，建议通过流程图或状态机模型辅助设计 Promise 链，以直观验证数据流与错误处理逻辑。
