进入任何一个还在维护的 AngularJS 老项目，你迟早会跟then、catch、finally这几个 Promise 方法打照面。说句实话，AngularJS 的$q虽然不如原生 Promise 或现代框架里那些实现那么“标准”，但它的链式调用模型其实是相当完整的。很多人用着用着就开始懵：finally里面的返回值到底传不传得下去？catch为什么有时候接不住错误？then的第二个参数和catch到底有什么区别？这篇文章就把这些语义和执行规则彻底讲透，顺带给出我这些年维护老项目时验证过的最稳写法。
这篇文章适合谁？一类是正在接手 AngularJS 遗产项目的开发者，你每天都要和$http、$q打交道；另一类是想把 Promise 基础打牢的人，因为 AngularJS 的$q和标准 Promise 在核心语义上高度一致，把这套规则搞明白，你切到 Vue 2 的 Promise 或原生 Promise 也几乎无障碍。
1. Promise 链在 AngularJS 里的底层执行规则
1.1 then 的两个参数远比看上去复杂
先从一个最基础但最容易忽略的事实说起：AngularJS 的 Promise 实例上有then(successFn, errorFn)，这个then可以接收两个回调，第二个回调用于处理失败。很多人以为：
promise.then(handleSuccess, handleError)和
promise.then(handleSuccess).catch(handleError)是一样的。在绝大多数场景下，结果确实一样，但有一个非常关键的差异：then自带的第二个回调，接不住自身第一个回调抛出的异常。
来看一个我实际踩过坑的例子：
var p = $q.when('ok'); p.then(function() { throw new Error('boom'); }, function(err) { // 这个回调根本不会执行 console.log('catch error:', err); });上面的throw new Error('boom')发生在then内部的成功回调里。如果你用的是带第二个参数的写法，这个异常不会被第二个参数捕获，它会直接变成一个 rejected promise，然后顺着链往下找下一个catch。但如果你的代码写成了p.then(success).catch(error)这种链式结构，catch就能接住success里抛出的异常。
这条规则几乎是所有“为什么我的错误没被处理”问题的根源。我在真实项目里见过很多次，有人在then里写了一个网络请求，没加return，然后错误回调没触发，前端页面毫无反应，最后排查半天发现是回调内部的 TypeError 被“吞”了，或者根本跑到了全局未处理的地方去了。
1.2 return 的三条黄金规则
在 AngularJS 的 Promise 链里，每个then回调中return什么，直接决定了下游的状态。这也是$q和原生 Promise 最统一的部分。我把这三条规则称为黄金规则：
规则一：return一个普通值（字符串、对象、数组），这个值会被包装成一个 resolved promise，传递给下一个then回调。
规则二：return一个 promise，那么下一个then会等待这个 promise 完成后，再拿到它 resolve 出来的值。
规则三：回调内部throw一个异常，或者return $q.reject(reason)，这个链会立刻变为 rejected，跳过后续所有then成功回调，直达第一个catch。
看代码就清楚了：
$q.when('step0') .then(function(val) { console.log(val); // step0 return 'step1'; // 普通值 }) .then(function(val) { console.log(val); // step1 return $http.get('/api/data'); // promise }) .then(function(response) { console.log(response.data); throw new Error('接口格式不对'); }) .catch(function(err) { console.log('error:', err.message); // error: 接口格式不对 });这个链路每一步都清晰而且可控。实际开发中，最容易犯的错就是“忘记return”。尤其是在第一个then里面发了一个异步请求，但没有把它return出去，那么第二个then立刻执行，拿到的值永远是undefined，而且第一个请求的失败也不会被后面的catch捕获。这个问题非常隐蔽，因为代码看起来是链式的，实际行为却是断裂的。
1.3 回调执行时机：异步总是异步
$q的 Promise 回调不会同步执行，即使 promise 已经处于 resolved 状态，你注册的then回调也会被放入一个任务队列，并在下一个$digest周期里被执行。这意味着什么？
在 AngularJS 的控制器里，你用$http.get().then()更新$scope，根本不需要手动调$rootScope.$apply()。因为$q的调度机制和内部 digest 循环是钩在一起的。这个机制在省事的同时也带来一个坑：如果你是在一个“非 Angular 上下文”里手动 resolve 了一个 defer，比如在某个第三方库的setTimeout回调里调用了deferred.resolve(data)，同时外部没有触发任何 digest，那么你的then回调可能不会立即执行，界面也不会刷新。这种情况下通常的解法是把调用放进$timeout或者手动包一层$rootScope.$apply()，而不是去怀疑 Promise 本身坏了。
另外一个常见误区是：给同一个 promise 注册多个then，这些回调之间的执行结果不会互相传递。例如：
var req = $http.get('/api/data'); req.then(function(res) { console.log(res.data); // 原始 response }); req.then(function(res) { console.log(res.data); // 仍然拿到原始 response });这两种写法是“分支”而不是“链式”。第一个then的返回值不会作为第二个then的输入，因为它们是同一个 promise 上的两个独立订阅者。如果你想做数据的逐层加工，必须写成req.then(...).then(...)的链式结构，而不是把同一个 promise 保存下来反复调用then。
2. catch 与 finally 的语义边界
2.1 catch 到底能接住哪些错误
catch本质上就是then(null, errorFn)的语法糖。它接住的是“从链路上游到此位置之间”没有被处理掉的 rejected 状态。划重点：这里的“上游”不一定是紧挨着的那个then，它可以是中间任意一个抛出异常的步骤。
看一下这个链子：
$q.when('start') .then(function() { return $http.get('/api/a'); }) .then(function(resA) { if (!resA.data.valid) { throw { code: 'INVALID_DATA', message: '数据校验不通过' }; } return resA.data; }) .catch(function(err) { console.log(err.code, err.message); });在这个例子里，catch能接住两种错误：$http.get('/api/a')请求失败的 rejected 状态，以及第二个then里手动抛出的对象。两个都属于“未被上游处理”的失败，所以都汇聚到catch。
再注意一个点：catch接住错误后，只要它没有再抛出新的异常，链路会自动“恢复健康”。换句话说，从catch之后继续then，走的是成功分支。这是很多人不熟悉的一条语义。如果你希望catch之后仍然走失败分支，可以这样写：
.catch(function(err) { console.error(err); return $q.reject(err); // 继续维持 rejected })这个特性用好了很灵活，用不好就是灾难。我见过一个项目，在封装 API 服务时，catch里本来只想做日志上报，结果忘了重新 throw，导致所有接口失败后都“误成功”进入了下游逻辑，页面渲染出来一堆空数据，排查了很久。
2.2 finally 的执行时机与返回值悖论
finally的语义在 AngularJS 的$q和现代 Promise 里基本一致：无论如何，在链路的最终阶段执行一段清理代码，比如关掉 loading、释放资源。但有一个最常见的认知冲突，就是finally回调的返回值不会传给后面的then。
看代码：
$http.get('/api/user') .then(function(response) { return response.data; }) .finally(function() { return $http.get('/api/another'); // 这个 promise 不会被等待 }) .then(function(userData) { console.log(userData); // 拿到的还是 /api/user 的 data });我在老项目改造时特别容易遇到这个问题。有人以为finally里return一个 promise，后面的then会等这个 promise 完成并且拿到它的值。实际上不会。finally闭包里的返回值，对于外层来说基本是透明的。你可以在里面执行同步的清理操作，但如果想插入异步任务，最保险的方式是把它放到finally之前的位置，或者显式地返回一个新 promise 构建的链。
不过也不能说finally的返回值完全没有作用——如果你在finally回调里又抛出了一个异常，这个异常会把当前 promise 变成 rejected，并且会跳过后续的then，直达catch。这个行为很容易被忽略。因此在finally里尽量避免写可能抛错的操作，尤其不要在里面做复杂的对象属性判断，否则极有可能引入难以排查的“幽灵错误”。
2.3 finally 适合做什么：loading 状态的标准解法
finally最正确的打开方式，就是清理与展示状态无关的临时标记。以数据加载为例：
$scope.loading = true; $scope.errorMsg = ''; $http.get('/api/items') .then(function(response) { $scope.items = response.data; }) .catch(function() { $scope.errorMsg = '加载失败，稍后重试'; }) .finally(function() { $scope.loading = false; });注意这里then、catch、finally的书写顺序是固定的：先处理成功，再处理失败，最后清理。这既符合阅读直觉，也能保证finally永远最后执行。如果把finally写在catch前面，虽然对于同一个 promise 来说，最终所有回调都会执行，但finally之后如果再写catch，那个catch接到的状态仍然是链路上“未被处理”的状态。对于上面这个简单例子可能无所谓，但在复杂链路里会制造混乱。
3. 链式调用的执行顺序与结构设计
3.1 扁平化：别再把 Promise 写成回调地狱
AngularJS 项目中一个特别常见的坏味道，就是在then里继续写$http请求，然后再嵌套一个then。长此以往，代码的缩进会越来越深，错误处理也七零八落。Promise 的价值就在于扁平化。
推荐的结构是这样的：
$http.get('/api/user') .then(function(res) { return $http.get('/api/orders?userId=' + res.data.id); }) .then(function(res) { $scope.orders = res.data; }) .catch(function(err) { $scope.orderError = '订单加载失败'; });第一个then里返回第二个$http.get()的 promise，这样第二个then会等待它完成。整个链路是平铺的，错误统一由最下方的catch接住，代码的可读性和可维护性都上了一个台阶。
这里我补一句调试心得：当链路比较长时，尽量不要写一堆匿名函数。给每个then回调起一个函数名，或者至少加上注释。因为旧项目的报错堆栈经常是“一团乱麻”，匿名函数的堆栈信息几乎看不出是哪个环节出了问题。我曾经通过把大段匿名回调拆成命名函数，硬生生把一个需要半小时的排查压缩到了五分钟。
3.2 多请求并行：$q.all 的语义与分支
$q.all用于等待多个 promise 全部完成。它接收一个 promise 数组，返回一个 promise。数组里所有请求都成功时，then会拿到一个结果数组；只要有一个请求失败，整个$q.all就进入 rejected。
这个“一个失败，整体失败”的语义需要特别注意。一个常见的业务场景是：两个接口并行请求，即使其中一个失败，另一个成功的结果也希望能保留。如果直接写：
$q.all([$http.get('/api/a'), $http.get('/api/b')]) .then(function(results) { // 任何一个失败都到不了这里 }) .catch(function() { // 整体失败，但是你不知道是 a 挂了还是 b 挂了 });这种写法比较粗糙。我通常会在每个请求后面先挂一个catch，把失败信息转为“带标记的成功值”，这样$q.all永远不会被某个单点拖垮：
function settle(promise) { return promise.then( function(result) { return { state: 'fulfilled', result: result }; }, function(err) { return { state: 'rejected', error: err }; } ); } $q.all([settle($http.get('/api/a')), settle($http.get('/api/b'))]) .then(function(results) { // 每个结果都包含 state 字段，可以分别判断 });这段代码其实就是现代 Promise 里allSettled的一个手动实现。在 AngularJS 中没有原生allSettled，而这种包装方案在项目里已经被验证很可靠。
3.3 同一 promise 的多分支注册顺序
继续聊一个细节中的细节：同一个 promise 上的then、catch、finally，如果分开注册，它们的执行顺序是按注册顺序来的，但是彼此之间不会传递状态。比如：
var req = $http.get('/api/user'); req.then(successFn); req.catch(errorFn); req.finally(cleanFn);这三个回调都是直接挂在req上面的，互不干扰。errorFn接不到successFn里抛出的异常，cleanFn也不会影响successFn和errorFn的执行。这种现象在大型项目中经常导致“明明写了 catch，为什么异常完全没被处理”的疑问。关键就是：捕获上游异常，必须形成“链”，不能形成“星型分支”。
正确做法是把它们连成一串：
var chain = $http.get('/api/user') .then(successFn) .catch(errorFn) .finally(cleanFn);这样catch才能接住successFn里可能的异常，finally也才会在整条链结束后执行。
4. 实战推荐写法与封装模式
4.1 基础数据加载的标准范式
在控制器里写异步请求，我推荐一个固定模板。它不花哨，但非常稳：
$scope.loading = false; $scope.list = []; function loadList() { $scope.loading = true; $scope.errorMsg = ''; apiService.getList() .then(function(items) { $scope.list = items; }) .catch(function(err) { $scope.errorMsg = '列表加载失败，请检查网络'; $log.error('[getList] error:', err); }) .finally(function() { $scope.loading = false; }); } loadList();注意两点。第一，apiService.getList()是返回 promise 的 service 函数，控制器只负责编排展示逻辑，不要自己去$http.get一团。第二，catch里除了设置用户可见的错误信息，还必须$log.error记录完整错误，这样排查问题时有迹可循。只把错误信息放在页面上，等于把真正的原因藏起来了。
4.2 服务层封装：错误转换与可恢复策略
Service 层的 Promise 设计直接决定了整个项目的错误处理风格。我后来形成的原则是“接口层尽量少吞错误，只在靠近 UI 层处理展示逻辑”，但也要区分可恢复和不可恢复。
可恢复错误的典型场景是下拉框初始化失败。比如某个下拉框需要一个配置项，请求挂了，你不能让整个页面白屏。这时在 service 里返回默认值是合理的：
function getConfig() { return $http.get('/api/config') .then(function(res) { return res.data; }) .catch(function(err) { $log.warn('配置请求失败，使用默认配置', err); return { enableFeatureX: false, pageSize: 20 }; }); }不可恢复错误则必须继续向上抛，让最终调用方感知到失败：
function getUserProfile() { return $http.get('/api/profile') .then(function(res) { return res.data; }) .catch(function(err) { // 打包成更有业务含义的异常 throw { code: 'PROFILE_LOAD_FAILED', raw: err }; }); }上层接住以后，可以根据code字段决定弹什么样的提示。这种错误转换模式在老项目中非常适用，因为旧接口经常返回非标准状态，直接在catch里统一转一轮，能极大减轻控制器里的判断负担。
4.3 $http 拦截器与 Promise 链的联动
AngularJS 的$httpProvider.interceptors本质上也是一个基于 Promise 的处理管道。它可以统一处理 401、500 这些公共异常，但要注意拦截器里的responseError返回或抛出，会直接影响下游的 promise 状态。
实际项目中常见的配合是：拦截器统一处理登录过期，业务模块再各自处理页面级错误。拦截器里如果return $q.reject(error)，那么下游的catch仍能接到；如果拦截器里直接return $q.when(response)，下游就会按成功路径走。这个链条的语义和then的规则完全一致，所以你可以把拦截器理解为一个全局的、自动插入的then/catch层。
这里有一个小的设计建议：不要在拦截器里做“全局弹 toast”，也不要直接修改页面 scope。拦截器应该只做状态判断、错误归类、重新登录跳转，不关心视图。否则一旦拦截器逻辑出问题，整个应用的异常都会被扭曲，排查成本极高。
4.4 避免反模式：能用 $q.when 就别用 $q.defer
很多老代码里动不动就出现$q.defer()，然后手动 resolve、reject。实际上如果你已经有一个现成的 promise，或者有一个普通值，完全不需要自己造 defer。
// 反模式 function getSomething() { var deferred = $q.defer(); $http.get('/api/data').then(function(res) { deferred.resolve(res.data); }, function(err) { deferred.reject(err); }); return deferred.promise; } // 更好的写法 function getSomething() { return $http.get('/api/data').then(function(res) { return res.data; }); }第二种写法的好处是：链条是完整连续的，错误路径天然被保留，不存在手动 resolve/reject 过程中漏掉状态的问题。如果你遇到一个旧的 service 用了大量defer，重构时最优先做的事情就是把它替换成“直接返回原始 promise 的链式结果”。
我甚至建议项目里立一条规矩：涉及$http或任意 promise 时，除了极少数自定义包装场景，不允许出现$q.defer。这条规矩执行起来初期有点阻力，但成本非常低，收益却是实打实的——所有异步路径都是串起来的，没有“断头路”。
5. 常见问题速查表与排查实录
| 现象 | 常见原因 | 解法 |
|---|---|---|
catch没触发，错误在控制台报了，但是链子继续往下走 | then(success, error)第二个参数接不住success回调内部抛错 | 改用.then(success).catch(error)链式结构 |
| 内存中明明有 rejected promise，却没有任何提示 | AngularJS 的$q默认不打印未处理拒绝 | 在链尾加catch统一打日志，或封一个done方法 |
| 页面 loading 一直转不停 | finally里依赖了异步操作，或者前面某个分支提前 return 了 promise | 把 loading 清理放到链尾finally，确保catch之后执行 |
| 请求失败后仍进入了成功回调 | catch没有重新抛出，链路自动恢复为 resolved | 需要继续失败时使用throw err或return $q.reject(err) |
发了一个请求，后面的then却立即执行了 | 前面回调里没有return请求的 promise | 补上return $http... |
$q.all中一个接口失败，其他接口结果全部丢失 | $q.all整体立即 rejected | 给每个请求分别挂catch，转成带状态标记的对象 |
5.1 一个典型问题的全流程排查
有一次在某个管理后台里，列表页刷新时，偶尔会出现数据不刷新的情况，但接口有时会 500。表面的现象是用户点“刷新”按钮，loading 转一下就停了，表格数据还是旧的。
排查步骤是这样的：
第一步，在 service 的catch里打印日志，发现确实进入了失败分支，日志里有完整错误。但控制器里设置$scope.errorMsg的代码没有执行。为什么？因为 service 里catch之后用return defaultData把状态恢复成了 resolved。这其实是我有意设计的降级策略，但控制器的逻辑是“只要成功就刷新表格”，所以拿到的默认数据覆盖不了旧表格，或者被 UI 层误判为“无需更新”。
第二步，把 service 的降级策略改掉：只有真正返回了有意义的数据才走刷新，失败时仍然throw，把决定权交到控制器。
第三步，控制器里区分“失败提示”和“成功刷新”，并在finally里统一关闭 loading。
这个问题的根因就是catch的“吞掉异常并恢复成功”的语义被低估了。在项目里用降级数据时，一定要确认下游是否真的能正确处理。
5.2 老项目改造时的一个小技巧：为 $q 补一个 done 方法
AngularJS 原生$q不会像现代环境那样自动报告“未处理的 promise 拒绝”。所以很多异常在旧项目里被静默丢弃，尤其是那些 stopPropagation 一样的场景，错误早就被吞了。如果你的项目初期没精力处理所有异常链路，可以先做一个治标的方法：在模块初始化时给$q的 promise 实例挂一个done方法。
angular.module('app').config(function($provide) { $provide.decorator('$q', function($delegate) { var Promise = $delegate.prototype; // 或者直接通过内部函数包装 if (!Promise.done) { Promise.done = function() { this.catch(function(err) { // 统一打印或上报 $log.error('Unhandled Promise rejection:', err); }); return this; }; } return $delegate; }); });不过这个方案取决于你项目里的$q版本和结构，不保证完全兼容。更稳妥的做法是在你的 service 层统一返回链时，都把自己的日志挂在链尾，形成一个整体的“日志尾点”。从老项目重构的角度说，这能够让你在迁移过程中快速发现哪些接口其实一直是在失败的，只是被静默了。
5.3 迭代到链式：重构嵌套回调的三步走
如果眼前有一个非常旧的、回调嵌套严重的 AngularJS 模块，我建议不要一次性推倒重写，而是按步骤小步迁移。
第一步，找到最内层的异步调用，用$http返回 promise 的特性，把它改造成return $http...的形式。
第二步，把外层的回调拆成then，保持原逻辑不变，只改变结构。此时不追求最简，只追求等价。
第三步，把错误处理集中起来，用catch统一接住，并在链尾加上finally做收尾。
每一步都可以保持代码可运行，避免了“重构到一半，系统全挂”的窘境。我在一个几十万行代码的老项目里做过类似迁移，前后花了好几周，但风险一直是可控的，因为每次改动都是形态层面的替换，而不是行为层面的改写。
最后分享一个非常有用的小习惯：写 Promise 链时，先想清楚这条链的“出口状态”是什么。是成功拿数据？失败给提示？还是无论怎样都重置 UI？想清楚出口之后，再倒着设计then/catch/finally的摆放位置。这个方法比记住任何规则都实用——因为它逼着你从执行结果出发，而不是从语法片段出发。AngularJS 虽然老了，但$q里这套 Promise 设计，还是值得静下心来吃透的。
 深度拆解)
