导读：商城购物车页面加载慢，用户加购后要等2秒才能看到结果，流失率高达30%。本文从接口优化、缓存策略、渲染优化三个维度，完整复盘一次购物车性能优化，把首屏加载从2.1秒降到180ms。
一、先说说问题有多严重
我们做电商的朋友都知道，购物车是整个转化链路的关键节点——用户加购成功后如果页面加载慢，很多人就直接关掉了。
之前我们商城的购物车页面，首屏加载时间是2.1秒，接口响应平均1.8秒。更夸张的是，用户加购一件商品后，要等2秒才能看到购物车数量更新。
数据不会说谎：
- 购物车页面跳出率：32%
- 加购到下单转化率：只有18%
- 用户反馈："每次加购都卡半天，我都不想买了"
老板给的目标是：把购物车首屏加载压到500ms以内。
二、先定位问题，别上来就优化
很多人优化性能上来就加缓存、压缩图片，结果发现根本不是这些问题。我们先做了一轮完整的性能诊断。
用Chrome DevTools的Performance面板跑了一遍，发现问题出在三个地方：
问题1：接口太慢
购物车接口平均响应1.8秒，其中：
- 商品信息查询：800ms
- 价格计算：500ms
- 库存校验：300ms
- 其他：200ms
问题2：渲染太重
购物车页面有50多个商品SKU，每个SKU都要渲染图片、价格、库存、优惠信息，DOM节点超过2000个。
问题3：重复请求
页面加载时发了8个请求，其中3个是重复的。
三、接口优化：从1.8秒到300ms
3.1 合并接口
之前购物车页面要调3个接口：
- /api/cart/list - 购物车商品列表
- /api/product/info - 商品详情
- /api/promotion/calc - 优惠计算
我们把这三个接口合并成一个：/api/cart/detail
效果：请求数从8个降到3个，接口响应从1.8秒降到800ms。
3.2 加Redis缓存
商品信息是变化很慢的数据，我们加了Redis缓存：
- 商品基础信息：缓存1小时
- 价格信息：缓存5分钟
- 库存信息：实时查询（不能缓存）
效果：接口响应从800ms降到400ms。
3.3 异步计算优惠
优惠计算是最耗时的（500ms），因为要算满减、折扣、优惠券、会员价。
我们改成异步计算：
- 先返回商品列表和基础价格（200ms）
- 优惠计算在后台异步进行
- 算完后前端再更新价格
效果：首屏接口响应从400ms降到200ms。
四、渲染优化：从2000个DOM到500个
4.1 虚拟列表
购物车商品多的时候（比如50个SKU），一次性渲染所有商品会很慢。
我们用了虚拟列表：只渲染可视区域内的商品，滚动时动态加载。
效果：DOM节点从2000个降到500个，渲染时间从800ms降到100ms。
4.2 图片懒加载
商品图片是最大的资源。我们做了图片懒加载：
- 可视区域内的图片才加载
- 用低质量占位图先显示
- 加载完成后再替换
效果：首屏图片加载从1.2秒降到300ms。
4.3 骨架屏
用户体验上，我们加了骨架屏：
- 页面加载时先显示骨架屏
- 数据加载完成后再渲染真实内容
效果：用户感知加载时间从2.1秒降到500ms（虽然实际加载时间没变，但感知快了很多）。
五、最终效果
优化完之后的数据：
- 首屏加载时间：2.1秒 → 180ms
- 接口响应时间：1.8秒 → 200ms
- 购物车跳出率：32% → 15%
- 加购到下单转化率：18% → 28%
老板很满意，说这是今年ROI最高的一次优化。
六、踩过的坑
坑1：上来就加缓存
一开始我们直接给所有接口加了缓存，结果价格信息缓存了5分钟，用户改了优惠券价格没变，被用户投诉了。
坑2：虚拟列表兼容性
虚拟列表在低端手机上有卡顿，因为滚动时要频繁计算位置。后来我们加了防抖优化才解决。
坑3：骨架屏太丑
一开始骨架屏做的很丑，用户以为页面坏了。后来我们参考了淘宝的骨架屏样式，才好看多了。
写在最后
购物车性能优化这件事，说复杂也复杂，说简单也简单：
- 先定位问题，别上来就优化
- 接口优化是大头，合并请求+加缓存+异步计算
- 渲染优化用虚拟列表+图片懒加载
- 用户体验上用骨架屏，感知比实际更重要
我们当时前三天都在"是不是CDN的问题"、"是不是图片太大了"这种猜测里浪费时间，后来用Performance面板一跑，才发现问题出在接口上。
性能优化没有银弹，但有几个红线值得记：接口要快、渲染要轻、感知要好。这三个做到位，用户体验就不会差。
