AngularJS双向绑定实战：从零搭建宠物商城全记录

搞过几个电商类的单页应用之后，我一直觉得AngularJS是个“爱恨交织”的选择——它的双向绑定确实爽，可一旦数据流不按套路走，排查起来也真让人头疼。这次用AngularJS做宠物商城，前前后后花了差不多两个月，从商品列表到购物车再到结算表单，把框架的脏检查机制、指令复用、服务层设计全都实战了一遍。如果你正准备用AngularJS做商城类项目，或者对它的双向绑定机制只停留在“会用但不懂原理”的阶段，那么这篇分享应该能帮你少走不少弯路。

文章里的代码和方案都是我在实际项目中跑通的，参数和写法可以直接拿去参考。我不打算给你堆一堆框架文档里已经写烂的东西，而是按着“项目拆解 — 机制解读 — 代码实现 — 问题排查”这条主线，把宠物商城从零搭出来的全过程，以及踩坑后的解决思路，完整捋一遍。

1. 项目拆解：宠物商城的核心需求与AngularJS的契合点

1.1 宠物商城有哪些核心模块

任何商城类项目，不管面向宠物还是面向服装，骨架基本都是同一套：商品展示、分类筛选、购物车、订单结算，然后是会员中心和后台管理。宠物商城在此基础上还有几个特色场景，比如按宠物种类（猫、狗、鱼、爬宠）分类、按体重区间推荐口粮、展示宠物用品的用户评价和评分等等。

我当时梳理出的核心模块如下：

• 商品模块：商品卡片展示、多条件筛选（种类、价格区间、品牌）、商品详情页、库存状态。
• 购物车模块：加入购物车、修改数量、删除商品、实时计算小计和总价、优惠码输入。
• 订单模块：收货人表单、地址选择、支付方式选择、订单提交前的校验。
• 会员模块：登录状态管理、购物车与用户身份绑定、收藏列表。
• 列表页的分页与加载状态。

这些模块交互密度不低，特别是购物车和筛选部分。数量一改，总价要立刻变化；筛选条件一勾，商品列表要立刻刷新；表单一行没填完，校验状态要实时反馈。毋庸置疑，这类场景就是AngularJS的舒适区——数据驱动视图，视图反过来又影响数据，双向绑定让这些联动逻辑省掉了一大堆手动操作DOM的代码。

1.2 为什么选择AngularJS而不是Vue或React

放到现在来看，新项目选AngularJS确实有点“考古”的意味，但我这个项目启动时，Vue还在2.x早期，React生态的Redux也才刚普及不久，AngularJS 1.x恰恰是社区资料最全、上手门槛最低的选择。更重要的是，团队里几个前端之前用AngularJS做过内部管理系统，模板语法、依赖注入那一套已经很熟，宠物商城这种中后台加C端页面的混合体，用它开发效率最高。

从技术特性上讲，AngularJS有几个点正好打在商城需求上：

• 双向绑定解决“表单密集型交互”：商城就是表单怪兽，搜索框、筛选器、购物车数量、优惠码输入、收货地址表单，全部需要实时联动。
• 指令系统适合封装可复用UI：商品卡片、评分星星、数量选择器，每个页面都可能用到，用自定义指令封装后到处插。
• 依赖注入天生好测试：CartService、ProductService、OrderService全部注入到控制器里，业务逻辑和视图解耦，后面写单元测试也方便。

当然，AngularJS的缺点我也很清楚，比如脏检查的性能瓶颈、作用域继承的坑、以及整个框架对新手不那么友好的“魔法感”。但这不影响它在当年的语境下是一个落地能力很强的框架。如果你现在仍然因为某些老项目原因在维护AngularJS代码，这篇文章里的思路一样能帮你把代码理得更顺。

2. 双向绑定机制：商城数据流的“隐形管道”

“angularjs双向绑定”这个热词，确实是理解整个框架的钥匙。很多初学者只记得一句话：“视图变了数据变，数据变视图变”，但真正到了排查性能问题或者视图不更新的时候，才发现自己根本不知道背后发生了什么。

2.1 双向绑定的工作原理：脏检查到底在检查什么

AngularJS的双向绑定，底层依赖的是$scope对象和一套名叫“脏检查”（dirty-checking）的机制。你可以把$scope理解成连接视图和控制器的“数据载体”，视图里的输入框会读取$scope上的属性，控制器里改数据也改的是$scope上的属性。

当你在模板里写ng-model="cartItem.quantity"，AngularJS其实做了两件事：一是给这个输入框注册了一个$watch监听，二是把输入框的值和$scope.cartItem.quantity建立了映射。当用户输入新数字，浏览器触发input事件，ng-model指令捕获到这个事件后，会立刻把输入值写回$scope，然后调用$apply触发一轮$digest循环。

$digest循环干了什么？它会把所有注册过的$watch监听全部跑一遍，看看$scope上的值相比上一轮有没有变化。如果有变化，AngularJS就会去更新对应的DOM绑定。这不是检查一次就完事，因为一个监听的回调里很可能又改了另一个$scope属性，所以要循环检查，直到连续两轮检查结果完全一致，或者循环次数超过10次的上限。超过上限就会抛出一个我们都很眼熟的错误：Maximum iteration limit exceeded。

很多人在项目里遇到的视图不更新问题，根子往往不在双向绑定本身，而是数据变化发生在了AngularJS的“管辖范围之外”。比如你在setTimeout回调里改了$scope上的数据，浏览器确实执行了你的代码，但AngularJS根本没有感知到这次修改，自然不会跑$digest循环，视图自然也就纹丝不动。这种情况需要手动调用$scope.$apply()，或者用$timeout服务来包一层。

2.2 商城场景里的双向绑定：哪些地方用起来最爽

理论说完，回到宠物商城本身。双向绑定在商城项目里应用最舒服的，我总结下来有三个场景。

第一个是搜索框加筛选条件的“即时过滤”。页面上有个搜索框输入“猫粮”两个字，下面的商品列表要立刻把匹配的结果刷出来。用AngularJS写，只需要在控制器里维护一个searchText字段和一个categoryFilter字段，然后在ng-repeat上接一个filter过滤器：

$scope.searchText = ''; $scope.categoryFilter = ''; $scope.changeFilter = function(val, type) { if (type === 'category') { $scope.categoryFilter = val; } }; $scope.filterProducts = function(product) { var matchSearch = !$scope.searchText || product.name.indexOf($scope.searchText) !== -1 || product.description.indexOf($scope.searchText) !== -1; var matchCategory = !$scope.categoryFilter || product.category === $scope.categoryFilter; return matchSearch && matchCategory; };

模板部分用ng-repeat="product in products | filter:filterProducts"，用户每敲一个字符，searchText变化，触发$digest，列表立刻重新过滤。整个过程中我没有手动去操作任何一个DOM节点，也没有去监听任何键盘事件，这就是双向绑定带来的最直接的效率提升。

第二个是购物车数量与金额的联动。用户把猫罐头数量从1改成3，小计、运费、总价要立刻跟着变。我在控制器里只需要写一个计算总价的方法，然后在模板里直接调用：

<tr ng-repeat="item in cart.items"> <td> <input type="number" ng-model="item.quantity" ng-change="updateSubtotal(item)" /> </td> <td class="text-right">{{ item.quantity * item.price | currency : '￥' }}</td> </tr> <tr> <td colspan="2" class="text-right">总价：{{ getCartTotal() | currency : '￥' }}</td> </tr>

getCartTotal()在模板里每次脏检查都会被调用一次，所以购物车数量变了，总价自然就跟着变了。这种做法简单直观，唯一需要注意的是，如果计算逻辑特别复杂，频繁调用会影响性能。优化方案是改成监听购物车items列表的变化，然后主动去更新一个cartTotal字段。

第三个是优惠码输入。用户输入“PET50”，如果码有效，立刻在界面上显示出“已优惠50元”，无效则显示红色提示。这个逻辑用ng-change加一个validateCoupon方法就能轻松实现，ng-class根据校验结果切换样式，完全不用写addEventListener和classList.add/remove。

2.3 双向绑定的坑：watch太多之后的性能问题

双向绑定好用，但代价是每一个绑定都是一个$watch，而$digest时不管你的数据有没有变，所有$watch都会被检查一遍。宠物商城商品列表原本只有几十个商品时没问题，但如果商品数量到了几百上千，再加上每个商品卡片上有五六个绑定字段（图片、名称、价格、库存、评分、加入购物车按钮的状态），页面就会出现肉眼可见的卡顿。

我实测下来的一个经验是：单个页面上的$watch数量超过2000以后，每次输入或者点击操作造成的卡顿就已经很明显了。宠物商城首页商品卡片加筛选条件加购物车图标上的角标数量，轻松就能突破这个数字。

针对这个问题的避坑方案，我放在后面第5章详细说，这里先提前剧透三个方向：一是ng-repeat加上track by减少DOM重建；二是用::一次性绑定语法，让基本不会变的字段（比如商品编码、图片URL）只被监听一次；三是把不需要实时更新的内容，从$scope上挪到指令内部的link函数里去处理，完全不注册$watch。

3. 从零搭建宠物商城：项目结构与核心功能实现

下面进入实操环节。我尽量把每一步的意图说清楚，告诉你为什么这样做、有没有其他选择、各自代价是什么。

3.1 项目目录结构与依赖引入

AngularJS项目不需要什么复杂的构建工具起步，早期我甚至直接用script标签引入文件就能跑起来。但商城项目模块一多，文件碎片化之后，还是建议用一套清晰的目录结构。我当时的项目结构如下：

pet-shop/ ├── index.html ├── app/ │ ├── app.js # 根模块定义、路由配置、全局常量 │ ├── controllers/ │ │ ├── product-list.js │ │ ├── product-detail.js │ │ ├── cart.js │ │ └── order.js │ ├── services/ │ │ ├── product-service.js │ │ ├── cart-service.js │ │ └── order-service.js │ ├── directives/ │ │ ├── product-card.js │ │ ├── rating-stars.js │ │ └── quantity-input.js │ └── partials/ │ ├── product-list.html │ ├── product-detail.html │ ├── cart.html │ └── order.html └── assets/ ├── css/ └── img/

这种按功能类型分层的做法，在AngularJS项目里最普适。控制器只做“粘合层”的工作：从服务拿数据、把数据放到$scope上、接收视图里的交互事件并调用服务方法。真正的业务逻辑（比如购物车的增删改查、优惠价计算）全部下沉到service里，这样视图层即使整个换掉，核心逻辑也不受影响。

依赖方面，我用的核心库是AngularJS 1.7.8，这是1.x系列里维护时间最长、坑相对最少的版本。路由用了ui-router，因为商城的商品详情页、购物车、结算页之间不仅有简单跳转，还有不少“嵌套视图”需求，比如商品列表页里点击某个分类，要同时更新左侧分类高亮和右侧商品列表，ui-router的命名视图和嵌套状态比ngRoute要灵活得多。

3.2 商品列表页：数据从哪来、怎么渲染

商品数据在真实项目里肯定来自后端API。我在开发阶段先用了一份本地json数据文件模拟接口，等后端接口的Swagger文档出来之后再切换成真正的$http请求。这一步对前后端并行开发很有用，你得在ProductService里把数据源封装好，让控制器感知不到数据来源的差异。

ProductService的简化写法：

app.factory('ProductService', ['$http', '$q', function($http, $q) { var PRODUCT_API = '/api/v1/products'; return { getAll: function() { return $http.get(PRODUCT_API).then(function(res) { return res.data.data; }); }, getById: function(id) { return $http.get(PRODUCT_API + '/' + id).then(function(res) { return res.data.data; }); } }; }]);

商品列表的控制器里，拿到商品数组之后放在$scope.products上，模板用ng-repeat渲染卡片。这里有个细节必须提：ng-repeat遍历数组时，默认会为每一项添加一个唯一的$$hashKey，如果列表数据频繁从接口刷新，每次都会重新生成$$hashKey，导致整个列表的DOM重建，影响体验。

解决办法是ng-repeat加track by：

<div class="product-card" ng-repeat="product in products track by product.id"> <!-- 商品卡片内容 --> </div>

track by product.id告诉AngularJS用商品的id字段来识别每个元素，而不是默认的$$hashKey。这样即使整个products数组被替换，只要id没变，对应的DOM节点就不会被重建。这个习惯我从这个项目之后一直保持到现在，因为不管是AngularJS还是Vue的v-for，都支持类似的key机制，原理完全相通。

3.3 购物车模块：CartService的设计与总价计算

购物车是整个宠物商城里逻辑密度最高的模块。我建议从一开始就把购物车状态封装成服务，而不是直接挂在控制器上，因为商品列表页要往购物车加东西、详情页也要加、购物车页面要改数量，如果每个控制器各自维护一份购物车数据，同步就是一场灾难。

CartService的核心方法如下：

app.factory('CartService', [function() { var items = []; var listeners = []; function notifyChange() { angular.forEach(listeners, function(fn) { fn(); }); } return { getItems: function() { return items; }, addItem: function(product, quantity) { var found = null; for (var i = 0; i < items.length; i++) { if (items[i].productId === product.id) { found = items[i]; break; } } if (found) { found.quantity += quantity; } else { items.push({ productId: product.id, name: product.name, price: product.price, quantity: quantity }); } notifyChange(); }, removeItem: function(index) { items.splice(index, 1); notifyChange(); }, updateQuantity: function(index, quantity) { if (quantity <= 0) { this.removeItem(index); return; } items[index].quantity = quantity; notifyChange(); }, getTotal: function() { var total = 0; for (var i = 0; i < items.length; i++) { total += items[i].price * items[i].quantity; } return total; }, onChange: function(callback) { listeners.push(callback); return function() { var idx = listeners.indexOf(callback); if (idx !== -1) listeners.splice(idx, 1); }; } }; }]);

这里有一个值得展开的设计点：为什么addItem里要判断是否已有同类商品，而不是无脑增加一条新记录？因为用户很可能会重复点击“加入购物车”，如果每次都新插入一条记录，购物车列表里就会出现好几行一模一样的产品，显得很不专业。合并数量这种处理，是商城购物车的“基本礼仪”。

数量变化之后要重新计算金额，我上面的写法是模板里直接调getTotal()。这个方法的性能隐患在购物车条目很少的时候完全看不出来，但如果以后要支持几百条购物车记录，就要改成“在updateQuantity里计算好总价并缓存到total字段”，让模板只绑定total变量，而不是每轮脏检查都去遍历一次列表。

3.4 订单表单：用AngularJS表单校验拦截无效提交

订单页面需要收集收货人信息，包括姓名、电话、地址、邮箱，另外还要选支付方式。AngularJS内置的表单校验是我当时最看重的功能，原因很简单：它能让我少写大量手动校验DOM类名的代码。

AngularJS表单校验的核心是form的name属性加ng-model，配合$valid、$dirty、$touched这些状态。比如电话字段的判断：

<form name="orderForm" novalidate ng-submit="submitOrder(orderForm)"> <div class="form-group"> <label>手机号</label> <input type="text" name="phone" ng-model="order.phone" ng-pattern="/^1[3-9]\d{9}$/" required /> <div class="error-msg" ng-show="orderForm.phone.$dirty && orderForm.phone.$invalid"> 请输入11位有效手机号 </div> </div> <button type="submit" ng-disabled="orderForm.$invalid">提交订单</button> </form>

这里说一下novalidate的作用。AngularJS希望由自己来控制表单校验，所以要在form标签上加上novalidate，让浏览器原生的HTML5校验机制不生效，否则浏览器会在AngularJS处理之前就弹出一个系统校验提示，两个体系混在一起会产生奇怪的交互体验。

ng-pattern直接接受正则表达式，校验手机号、邮政编码这类固定格式非常方便。ng-disabled="orderForm.$invalid"会在表单存在任何校验错误时自动禁用提交按钮，这比“用户点提交后弹个警告框”的体验友好得多。

另外一个实用细节是ng-messages指令。AngularJS 1.3之后的版本支持用它来集中管理报错信息的显示逻辑，不用写一大堆ng-show加$dirty加$invalid的组合判断。写法更清爽：

<div ng-messages="orderForm.phone.$error" ng-show="orderForm.phone.$dirty" role="alert"> <div ng-message="required">手机号不能为空</div> <div ng-message="pattern">手机号格式不正确</div> </div>

我自己是从老式的ng-show写法趟过来的，后来重构才换成ng-messages。别小看这个改动，当一个表单有七八个字段、每个字段又可能报两三种不同错误时，ng-messages能把模板代码量压缩掉一半以上。

4. 服务、指令与路由：商城代码的组织之道

控制器代码越写越大的时候，就是你需要停下来重新思考架构的时候。宠物商城做到一半，我发现商品列表控制器和购物车控制器里各有一大段重复逻辑，于是我开始着手把它们抽成服务，然后用自定义指令把那些反复出现的UI片段封装起来。

4.1 Service与Factory的区别：用对才能好测试

AngularJS里创建服务有两种常用方式：service和factory。简单理解，factory返回一个自定义的对象，可以是任意类型；service则是用new方式实例化一个构造函数。在宠物商城里，两种都用到了，但大部分场景我用factory，因为它更直接，返回一个“直白的对象字面量”就够了。

不过这里有一个更重要的约定：无论用哪种方式，服务都应该是“无状态共享”的，至少服务内部暴露给控制器的应该是清晰的方法，而不是让控制器直接操作服务内部的私有数组。我在CartService里暴露了getItems()、addItem()、removeItem()、updateQuantity()、getTotal()这些明确的方法，控制器只能在业务层面调用它们，无法绕过方法直接修改购物车数据。这样做的好处是，所有数据变动都集中在service内部，以后想加日志、想加数据持久化（比如存到localStorage），只需要改service内部，所有控制器自动受益。

实际项目里我还给CartService加了localStorage持久化。用户刷新页面后购物车数据还在，体验提升非常明显。这个逻辑放在service内部加两三行代码就能实现：

function saveToStorage() { localStorage.setItem('pet_shop_cart', angular.toJson(items)); } function loadFromStorage() { var saved = localStorage.getItem('pet_shop_cart'); if (saved) { items = angular.fromJson(saved); } }

angular.toJson和angular.fromJson会在序列化时忽略$$hashKey之类的内部属性，比直接用JSON.stringify更干净。

4.2 自定义指令：封装商品卡片与评分星星

宠物商城里多个页面都会展示商品卡片：首页热卖推荐、列表页搜索、详情页的“相关推荐”。如果每个页面都复制一大段商品卡片HTML，后续改样式或者添加“加入购物车”按钮时就得到处改，很容易漏。

我的做法是封装一个productCard指令：

app.directive('productCard', [function() { return { restrict: 'E', templateUrl: 'app/partials/directives/product-card.html', scope: { product: '=', onAdd: '&' }, link: function(scope, element, attrs) { scope.addToCart = function() { scope.onAdd({ product: scope.product, quantity: 1 }); }; } }; }]);

这里有几个关键点。restrict: 'E'表示这个指令只能作为自定义元素使用，也就是<product-card product="p" on-add="addToCart(p)"></product-card>这种写法，语义更清晰。scope里通过=传对象、通过&传回调，让指令与外部完全解耦。我不希望指令内部直接依赖CartService，那样的话指令就变成了全局单例的耦合者，很难复用。现在调用方可以自主决定“加入购物车时到底要做什么”，比如有的页面加完还要弹一个提示框，有的页面加完要跳去购物车，这个差异完全由调用方控制，指令不做任何假设。

评分星星组件是另一个值得封装的东西。我实现了一个支持半星显示和点击评分的ratingStars指令：

app.directive('ratingStars', [function() { return { restrict: 'E', templateUrl: 'app/partials/directives/rating-stars.html', scope: { ratingValue: '=', readonly: '@', onRate: '&' }, link: function(scope) { scope.stars = [1, 2, 3, 4, 5]; scope.setRating = function(val) { if (scope.readonly === 'true') return; scope.ratingValue = val; scope.onRate({ rating: val }); }; scope.getStarClass = function(star) { return star <= Math.round(scope.ratingValue) ? 'star-active' : 'star-inactive'; }; } }; }]);

模板里用ng-repeat渲染5个星星，ng-click触发评分。用户评分之后调onRate回调，由父控制器决定把评分提交到接口还是临时显示。这个指令在商品详情页和评价列表里都复用了，把重复的星星UI和交互逻辑收敛到一个地方。

4.3 路由配置：ui-router的状态嵌套与页面守卫

商城项目里页面跳转关系比普通站点复杂得多。商品列表页有多种筛选状态、商品详情页要能记录来源、购物车为空时跳去首页、订单页需要校验是否已经登录。我用ui-router的$stateProvider来管理所有页面状态，核心状态定义如下：

app.config(['$stateProvider', '$urlRouterProvider', function($stateProvider, $urlRouterProvider) { $urlRouterProvider.otherwise('/products'); $stateProvider .state('products', { url: '/products', templateUrl: 'app/partials/product-list.html', controller: 'ProductListCtrl', controllerAs: 'vm' }) .state('product-detail', { url: '/products/:productId', templateUrl: 'app/partials/product-detail.html', controller: 'ProductDetailCtrl', controllerAs: 'vm' }) .state('cart', { url: '/cart', templateUrl: 'app/partials/cart.html', controller: 'CartCtrl', controllerAs: 'vm' }) .state('order', { url: '/order', templateUrl: 'app/partials/order.html', controller: 'OrderCtrl', controllerAs: 'vm', resolve: { loginRequired: ['$state', function($state) { // 这里做登录校验，未登录则跳转登录页 }] } }); }]);

resolve是ui-router里一个特别好用的机制，在进入订单页之前可以提前执行一些异步逻辑，比如确认购物车不为空、确认用户已登录。如果校验失败，在resolve阶段抛错或直接$state.go跳走，页面根本不会渲染，避免了用户看到一帧空白页面再被弹走的糟糕体验。

对于路由方式，如果条件允许现在的新项目我会建议直接用组件化路由，但AngularJS的老项目中ui-router已经是最成熟的选择。它的状态嵌套能力、命名视图和resolve机制，覆盖了一个商城项目绝大多数的页面管理需求。

5. 常见问题排查与性能优化实录

做宠物商城的过程中，我在这类框架上踩过的坑几乎都能归类成“视图没更新”“列表太卡”“作用域不对”三个大方向。下面把每个问题的排查过程和最终解法整理成一份速查表，附带我在项目里的实操经验。

5.1 视图不更新：$apply的时机和正确用法

最经典的场景：用户在页面点了“加载更多”按钮，你用setTimeout模拟一个异步请求，拿到新数据后赋给$scope.products，结果列表毫无反应。原因我在2.1说过——数据变化发生在AngularJS的上下文之外，$digest没有跑。

排查思路是先在数据赋值的地方加一行console.log，确认数据真的更新了，而不是后端返回的是空数组。确认数据有变化但视图没动，再考虑是不是$scope引用的问题。比如你直接给$scope.products重新赋了一个数组，这种整体替换一般没问题；但如果你是对$scope.products里的某个对象添加了新属性，AngularJS默认不会监听这个新属性，视图自然不会更新。解决办法是用$scope.$apply()包一层，或者更推荐用$timeout：

$scope.loadMore = function() { $timeout(function() { $scope.products = $scope.products.concat(newProducts); }, 300); };

$timeout其实会自动执行$apply，省得你手动调用。强烈建议不要手动调用$apply，因为你没法确定当前是不是已经处在$digest循环中。如果正在循环里又调用$apply，AngularJS会直接抛$digest already in progress错误，排查起来比原问题还麻烦。

5.2 列表卡顿：2000个watch怎么降到500个

我的宠物商城商品列表页，最开始每个商品卡片绑定字段有图片、名称、描述、价格、原价、库存、评分、分类标签、加入购物车按钮的ng-disabled状态，再加上ng-repeat本身，一个商品就轻松产生10个以上$watch。100个商品就突破1000个watch，每次输入筛选关键字时，页面都有明显迟滞。

我的优化方案有三个层次，从易到难：

• 加track by，避免列表整体重建。这一步能把最贵的DOM销毁重建开销省掉。
• 用一次性绑定::，把静态字段从watch体系里摘出去。商品编码、图片URL、品牌名称这些基本不变的字段，写成::product.imageUrl就不再被监听，直接减少大量watch。
• 把复杂的格式化逻辑挪到$scope之外。比如价格格式化、评分百分比计算，都预先处理成纯展示字段，模板里直接绑定，而不是每次都跑一个函数。

这里还要提一个很多人容易忽略的细节：filter过滤器在$digest循环中的开销非常大。购物车列表和商品列表的过滤操作，如果每次$digest都重新计算一遍，代价极高。我的做法是在控制器里监听筛选条件变化，手动完成过滤，把结果存到$scope.filteredProducts里，模板只绑定这个结果数组。这样筛选功能照用，但重计算只发生在条件变化的那一刻，而不是每次脏检查都全量执行。

5.3 作用域继承的坑：ng-repeat子作用域与controller as

AngularJS的作用域继承是原型继承，这意味着在子作用域里给父级属性重新赋值时，你不会真正修改到父级作用域的属性，而是会在子作用域上新建一个同名属性。经典翻车现场：

<div ng-repeat="item in cartItems"> <button ng-click="removeItem($index)">删除</button> </div>

$index没问题，但如果你在ng-repeat内部试图通过item.quantity = 0来“清空”购物项，你修改的只是子作用域里的item对象的属性，而item本身是从父作用域的cartItems数组里取出来的对象引用。因为对象是引用类型，所以修改属性还能通到父数组里；但如果你直接给item重新赋值item = null，就完全没用，只会创建一个局部变量。

避免这类问题最彻底的方式，是全面转向controller as语法。模板里用vm.xxx明确访问控制器实例上的属性，不再隐式依赖$scope。比如购物车控制器：

app.controller('CartCtrl', [function() { var vm = this; vm.items = []; vm.total = 0; vm.removeItem = function(index) { vm.items.splice(index, 1); }; vm.updateTotal = function() { vm.total = vm.items.reduce(function(sum, item) { return sum + item.price * item.quantity; }, 0); }; }]);

模板里对应写成ng-repeat="item in vm.items"，ng-click="vm.removeItem($index)"。controller as最大的优势是让“哪个控制器里的属性”一目了然，作用域继承带来的隐式覆盖问题从源头上被切断了。

下面是我整理的一个问题排查速查表，可以直接印出来贴在工位上：

5.4 页面跳转后控制器重复初始化：resolve与控制器生命周期

商城有一个典型场景：用户从商品列表页进入详情页，再点“加入购物车”后跳回购物车页面，发现购物车列表不见了。这通常是因为每次路由切换时，控制器都会重新执行一遍初始化逻辑，如果你的初始化逻辑里直接覆盖了vm.items = []或从服务重新拉数据，那么之前在购物车里积累的数据就会丢失。

我当时用CartService管理购物车，好处是数据存在service里，不会因为控制器重建而丢失。但新手容易犯的错是在控制器构造函数里执行vm.items = CartService.getItems()，看似拿到了引用，可如果后续对vm.items进行整体赋值（vm.items = []、vm.items = response.data），就会把service里的引用也替换掉，造成“我明明清空了页面上的购物车，但重新进入时购物车数据还在”或者相反“页面刷新了但购物车数据没了”的错乱。

稳定做法是只把CartService.getItems()返回的数组引用暴露给视图，所有的增删改都通过service方法操作。控制器里绝不直接vm.items = []清空，而是调CartService.clear()。这个边界在代码Review时值得反复强调。

另外，resolve除了做鉴权，还能优雅地处理“购物车为空时不进入订单页”的逻辑。在order状态的resolve里检查购物车购物项数量，为空则直接重定向到商品列表页，并弹一条“请先选购商品”的提示。这比在控制器里初始化后再判断，体验好得多。

实操心得：几个值得长期保留的AngularJS习惯

做完这个宠物商城，我对AngularJS的认知比之前任何一次都要深入。如果用一句话总结这段经历，那就是：双向绑定是AngularJS的“术”，而弄懂它背后的$digest循环和作用域机制，才是真正让你从“会写”变成“会修”的“道”。

如果让我现在再给做AngularJS项目的人几个习惯性建议，我会说：

第一，从第一天就用controller as语法，不要留恋原始的$scope注入方式。虽然两者最终会映射到同一套机制，但controller as能帮你规避掉大量作用域继承引发的隐性bug，代码审阅时也更容易看出数据到底属于哪个控制器。

第二，服务层是AngularJS项目的安全垫。购物车、用户信息、商品缓存这类跨页面数据，永远放在service里，让控制器只做转发。这个原则不只在AngularJS里成立，换到React或者Vue，状态管理的思路依然相通。

第三，性能问题要在写代码时预防，而不是上线后抢救。每次在模板里新增一个{{ }}绑定，心里就要默默记一笔：这会是第几个watch？如果页面卡了，先去检查哪些绑定是可以去掉的，再考虑换框架换方案。宠物商城项目里最让我挠头的一次性能优化，最后就只是删掉了一个不必要的过滤器外加两个一次性绑定，收益却立竿见影。

项目上线后，我还顺手把CartService改成了支持localStorage持久化的版本，用户关闭浏览器再打开，购物车里的三罐猫粮和那袋狗粮都还在，测试组的同事说这个细节让他们对页面好感度提升不少。说真的，AngularJS老归老，但只要你摸清了它的脾性，做个宠物商城这种体量的项目，它依然是一把非常称手的老工具。