uni-app实现京东式满减凑单实时提示的核心是watch购物车总价+computed差额+前端主动触发震动/角标更新，后端仅返回满减规则；购物车数据须挂载在vue响应式数据源（如vuex state）而非localstorage，通过computed计算总价并watch其变化，差额计算需加边界判断与缓冲阈值。
直接上结论：uni-app 实现京东式满减凑单实时提示，核心不是“弹窗”或“动画”，而是 watch 购物车总价 + computed 差额 + 前端主动触发震动/角标更新，后端只需返回当前满减规则（如 "threshold": 300, "discount": 50），不参与实时计算。
购物车总价变动如何被前端实时捕获
不能只靠 uni.setStorageSync 存完就完事——存是持久化，但 UI 响应必须依赖响应式数据源。常见错误是把购物车数组存在 localStorage 里，然后每次 getStorageSync 手动刷新页面，这会导致“凑单提示延迟一整页刷新”。
- 必须将购物车数据挂载在 Vue 实例的
data或 Vuex 的state.cart中（推荐 Vuex，尤其多页面共享） - 用
computed计算总价：cartTotal() { return this.cart.reduce((sum, item) => sum + item.price * item.quantity, 0) } - 用
watch监听总价变化：cartTotal(newVal) { this.checkCouponEligibility(newVal) }，而不是监听整个cart数组（性能差、易误触发） - 注意：
watch默认不 deep，但这里不需要 deep，因为总价是派生值，改数量/删商品都会触发cartTotal重算
凑单差额计算与提示逻辑怎么写才不翻车
满减规则通常由后端接口返回（例如 /api/coupon/rules），格式类似 { "type": "full_reduction", "threshold": 300, "discount": 50 }。前端不能硬编码阈值，否则活动一换就要发版。
- 差额 =
rule.threshold - this.cartTotal，但需加边界判断：if (this.cartTotal >= rule.threshold) { this.needAmount = 0; this.showTip = false; return; } - 显示文案别写死：“还差
128元” → 实际应为Math.ceil(rule.threshold - this.cartTotal)，避免小数（比如 299.99 元时显示“还差 0.01 元”很诡异） - 触发提示的临界点要设缓冲：不要等差额刚好 ≤ 50 才显示，建议
needAmount 就开始提示，给用户留操作空间 - 角标数字（如购物车图标右上角的
2）应和凑单状态解耦：它只反映未读消息或待结算数量，别强行绑定“还差 X 元”，容易语义混乱
用户感知强的反馈该用什么 API
京东/淘宝的“达标震动+文字高亮”不是纯 CSS 动画，而是调用原生能力增强确定性。uni-app 提供了跨端一致的轻量级 API，但要注意兼容性兜底。
- 震动反馈用
uni.vibrateShort()，仅 iOS 和 Android 支持，H5 环境静默忽略，无需额外判断；别用uni.vibrateLong()，用户会以为出错了 - 文字高亮靠 class 切换：
:class="{ 'tip-highlight': needAmount ，CSS 里定义 <code>.tip-highlight { animation: pulse 1.5s infinite; } - 千万别在
watch里反复调uni.showToast()——它会堆叠弹窗，且无法关闭。提示文案应内嵌在购物车固定区域（如结算栏上方），用v-if控制显隐 - 如果用户从商品页跳转到购物车页，首次进入时也要手动触发一次
checkCouponEligibility，否则初始态不提示
真正难的不是算差额，而是规则变更时前端如何无感适配。比如后端突然增加“满 300 减 50，再满 600 减 120”的阶梯规则，computed 里的逻辑就得支持多档位匹配——这时候别硬写 if-else，把规则数组传进来，用 rules.find(r => this.cartTotal >= r.threshold) 更稳妥。
