电商交易系统测试面试题

本文档包含 18 道电商交易系统方向的高频面试题，覆盖业务模型、商品库存、下单与价格、营销与秒杀、订单状态机、售后退款、履约、多端一致性、分布式事务、风控与大促保障。电商是国内互联网最大的业务方向，几乎所有大厂面试都会展开追问，准备时建议结合自己做过的项目把每题落到具体场景里。

一、业务模型与下单链路（5题）

Q1: 电商系统的核心业务域有哪些？典型分层架构是什么样？

答案：

回答这类宏观题，先把电商的「域」和「层」分开讲，面试官能听出来你是不是真的做过电商。

业务域上，主流电商系统通常拆成商品域、交易域、营销域、用户域、履约域、结算域六大块。商品域管 SPU/SKU、类目、属性、上下架；交易域管购物车、下单、订单、支付编排；营销域管优惠券、活动、价格计算；用户域管账号、收货地址、会员等级；履约域管仓储、拣货、发货、物流轨迹；结算域管退款、对账、商家结算。

分层架构上，可以按"接入层 / 业务层 / 数据层 / 外部依赖"四层来描述：

测试视角下，每一层都有自己的关注点：接入层关注协议、鉴权、限流、防爬；业务层关注业务规则、状态机、幂等、一致性；数据层关注事务、分库分表、缓存击穿；外部依赖关注超时、重试、降级。能把这张图画清楚，面试至少加 5 分。

Q2: 端到端测一笔订单要覆盖哪些链路？

答案：

一笔订单的端到端链路远比表面看的复杂，按时间轴拆大概十步。

下单前的浏览与加购，要覆盖搜索、商详、库存展示、价格展示、加购物车、跨端同步。这一步常出问题的是商品价格 / 库存 / 上下架状态在搜索、商详、购物车里不一致。

下单环节包括地址选择、优惠选择、运费计算、价格预算、风控前置校验、下单提交、订单生成。重点测幂等、价格一致性（前端展示价 = 后端计算价）、优惠冲突、库存预占。

支付环节包括拉起收银台、选支付方式、支付下单、回调到账、订单状态变更。重点测支付与订单的状态机一致性、回调幂等。

履约环节包括订单下传到仓、拣货、出库、物流、签收，重点测拆单合单、跨境清关、物流轨迹同步。

售后环节包括退款申请、退货流转、退款到账、订单关闭，重点测逆向库存回滚、优惠券退还、积分回退。

完整的回归测试集里，至少要保证「正向主流程 + 各种异常分支 + 售后逆向 + 取消订单」四条主线打通，每个分支再细分支付方式、优惠组合、商品组合、地址类型。一个成熟电商团队的核心回归用例通常在 2000~5000 条之间，自动化覆盖率 60% 以上。

Q3: SKU 和 SPU 是什么？测试时要关注哪些点？

答案：

SPU（Standard Product Unit）是标准产品单元，代表一个抽象商品，比如「iPhone 15 Pro」；SKU（Stock Keeping Unit）是库存单元，代表一个可售的具体规格，比如「iPhone 15 Pro 256G 黑色」。一个 SPU 通常对应多个 SKU。

测试时关注几个常见坑点：

属性维度匹配。SPU 上定义的销售属性（颜色、容量等）和 SKU 上的属性值组合是否完整、有没有遗漏组合或重复组合，缺一个 SKU 用户在前端可能选不到对应规格。

价格与库存维度。SKU 维度独立管理价格和库存，但部分活动是按 SPU 配置的（如全店满减），价格计算时要把 SPU 级活动正确下放到所有 SKU。

上下架状态。SPU 下架时所有 SKU 应同步不可售，SPU 在架但 SKU 售罄时商详按钮要变成"已售罄"。

切换体验。前端规格切换时价格、库存、图、详情要实时刷新，且和后端真实数据一致；选了一个无库存组合时要有"已售罄"提示而不是允许下单。

商详与搜索一致性。SPU 改类目、改主图、改描述后，搜索索引、推荐池、活动池的同步延迟要纳入测试，长延迟会导致用户看到的和下单后实际不一致。

Q4: 库存扣减时机有几种？怎么测超卖？

答案：

库存扣减时机本质上是「什么时候真正扣库存」的策略选择，常见三种。

下单扣减。用户下单成功立即扣库存，未支付订单超时再回滚。优点是不会超卖、用户体验稳；缺点是库存被预占率高，恶意刷单或大促时可能把库存"锁死"。京东主流采用这种方式。

支付扣减。下单不扣库存，付款成功才扣，未付款用户互相抢。优点是库存利用率高；缺点是高并发下可能出现"下单成功但支付时已售罄"的体验问题，对秒杀场景几乎不可用。

预占扣减（推荐）。下单时扣"预占库存"，支付后扣"实际库存"，未支付超时释放预占。是上面两种的折中，绝大多数电商生产环境采用这种方式。

测试维度上，超卖防控测试通常分三步走：

正向单线程功能。先把库存=1 的场景跑通，验证扣减、回滚、状态变更逻辑正确。

并发压测。用 JMeter 或自研工具发起远超库存数量的并发下单请求（比如库存 100，并发 1000），断言「实际成交订单数 ≤ 100」「数据库库存数不为负」「Redis 缓存与 DB 库存最终一致」。

故障注入。在压测过程中重启 Redis、断开主从、抛 5xx 异常，看库存是否依然不会超卖、未成交订单是否能正确回滚。

实战中常见的超卖根因有：扣减逻辑没用原子操作（UPDATE ... SET stock = stock - 1 WHERE stock > 0 是必须的，不能先查后扣）；Redis 与 DB 双写不一致；MQ 重试导致重复扣减；分布式事务超时回滚不完整。每一种都要专门设计场景验证。

Q5: 下单接口怎么做幂等？测试时怎么验证？

答案：

下单的幂等问题来自三类场景：用户网络重试、客户端按钮多次点击、网关重试。任何一种都可能让同一笔订单提交多次，必须从协议层就堵住。

主流方案是「客户端 Token + 服务端去重」。下单前端先调一个 getOrderToken 接口拿到一次性 token，下单提交时把 token 一起传到后端，后端用 Redis SET NX 写入 token，写成功才执行下单逻辑，已存在则直接返回上一次结果。也有用「业务唯一键」做幂等的，比如「用户 ID + 购物车快照 ID + 时间戳」哈希成幂等 key。

测试时按几个维度覆盖：

短时间高频重提。同一 token 在 1 秒内连续提交 100 次，断言只生成 1 笔订单，其余返回相同结果（不是错误，而是幂等命中）。

Token 过期。Token 设了过期时间（一般 5~10 分钟），过期后再用应该返回错误。

Token 跨用户。A 用户的 token 拿给 B 用户用，必须拒绝。

并发场景。多线程同时拿同一个 token 提交，断言只有一个成功、其余幂等返回，且最终订单只有一笔。

异常重试。下单接口在写订单后、返回响应前模拟超时或异常，客户端重试，断言不会产生重复订单。

幂等不仅要测下单接口，整条链路上的支付回调、库存扣减、MQ 消息消费、退款回调都要测幂等，每个节点的非幂等都可能导致资损。

二、价格、营销与秒杀（5题）

Q6: 电商价格计算引擎要测哪些点？

答案：

价格计算是电商系统出 P0 事故的高发区，几个亿的资损往往就在小数点几分钱的舍入上。测试要从「价格构成 + 优惠叠加 + 精度处理 + 边界场景」四方面覆盖。

价格构成上，一笔订单的最终金额至少由商品价、运费、税费、平台优惠（满减、券、积分）、商家优惠（店铺券）、会员折扣、首单优惠等组成。每一项都有独立规则，叠加顺序影响最终金额，必须先列清楚「规则优先级树」再设计用例。

优惠叠加规则上，要把可叠加、互斥、依赖关系做成矩阵：

每个组合都要有正向用例验证可叠加场景，反向用例验证互斥场景会被拒绝。

精度处理上，金额一律用 BigDecimal、禁用 double。舍入策略要明确（多数电商用 ROUND_HALF_UP，金融场景用银行家舍入），并对每一步计算结果都断言精度（一般 2 位小数）。一个典型 Bug 是「分摊优惠到多个 SKU 时小数点丢失 1 分钱」，要专门测「3 件商品 + 满 100 减 10」这类除不尽的场景。

边界与异常上，0 元订单、负数订单（资损）、超过 99999 元订单、单笔优惠超过商品价、商品价为 0 等场景必测。前端展示价和后端计算价不一致是电商最常见投诉，测试时要在订单提交前后各打一次价格快照做对比。

Q7: 优惠券测试怎么设计用例矩阵？

答案：

优惠券规则维度多，硬测会用例爆炸。实战通常用「正交分析 + 等价类 + 边界值」组合压缩用例数。

第一步先列出影响因素：券类型（满减/折扣/兑换）、面额、门槛、使用范围（全场/类目/店铺/单品）、叠加规则、领取限制（限领次数、新人专享、会员专享）、有效期（绝对/相对/活动期）、状态（未使用/已使用/已过期/已退款）。

第二步用「等价类」收敛每个维度，比如「使用范围」分四个等价类，每类取一个代表值。

第三步用正交表组合，覆盖关键交互。

具体测试场景至少包括：

领取限制。新人券非新人不能领；限领 1 张的券同一用户领第 2 次应失败；活动结束后不能再领。

使用门槛。订单金额刚好等于门槛（边界）；订单金额超过门槛；订单金额低于门槛 1 分钱（应不可用）；用了券后实付金额低于 0.01 元（业务规则）。

使用范围。仅限指定商品的券，购物车里混了不符商品时只对符合商品计算优惠；店铺券跨店铺下单时怎么分摊。

时间边界。券生效前 1 秒不能用；过期后 1 秒不能用；订单提交时券有效但支付时已过期。

状态流转。已使用的券退款后是否退还（部分退款是否退还）、订单取消是否自动退券、过期券不再回收。

实际项目里，电商团队通常把优惠券规则做成「规则配置 + 引擎执行」的形式，测试时除了功能用例还要测配置后台的规则正确性，并维护一份「规则变更回归集」。

Q8: 促销活动（满减、阶梯、N 元 M 件、赠品）有哪些测试要点？

答案：

促销活动比单券复杂，因为活动间的优先级、商品池的圈选、商家自营 vs 平台活动的关系都会带来组合爆炸。

满减活动测试要覆盖：满足门槛、刚好满足、未满足；活动叠加（满 100 减 10 + 满 200 减 25 时拿就高规则）；活动期内 vs 活动期外；活动商品被退款后是否还满足门槛、退款金额怎么算（按整单分摊还是按商品分摊）。

阶梯优惠（如满 100 减 10、满 200 减 25、满 500 减 80）。要验证只享受「最高档」、阶梯间过渡值（199.99、200.00、200.01）的金额计算。

N 元 M 件（3 件 99 元、第二件半价、买 1 送 1）。重点测多件商品组合时谁享受优惠（一般是「贵的优先、便宜的送」）、超过 N 件时多出来的件单独计价还是再凑一组、和券能否叠加。

赠品活动。赠品库存独立管理还是和正品共享、赠品退款是否一起退、用户退主商品时赠品要不要追回、赠品没库存时整单怎么处理（不送 / 替换 / 不能下单）。

优先级与冲突。多活动叠加时执行顺序常见为「单品 → 店铺 → 平台」，每一步算完再进下一步；活动互斥规则配置错误会导致用户拿到不该有的优惠（典型资损来源）。

实战中促销规则变化频繁，建议把规则文档化、自动化用例参数化（活动 ID 作为入参），新活动上线时通过新增数据驱动用例快速覆盖。

Q9: 秒杀系统的架构是什么样？测试要覆盖哪些维度？

答案：

秒杀场景特点是「瞬时高并发、库存极少、用户预期高」，架构上必须把请求层层削减，避免压垮核心交易系统。

整条链路核心思想是「层层过滤」：CDN 扛住静态流量，WAF 拦黑产，LB 做总量限流，秒杀网关做用户级限频和参数校验，Redis 做预扣库存（原子操作 DECR），MQ 削峰后异步落库。

测试要覆盖以下维度：

功能正确性。预热数据正确，开抢前不能下单，开抢后限购规则生效（每人 1 件），库存售完后立即返回"已售罄"。

并发与超卖。1000 库存 + 10 万并发场景下断言成交数 ≤ 1000，没有负库存，没有重复下单。

限购与防作弊。同一用户多次点击只能成功 1 次；同一 IP 异常高频请求被拒；模拟脚本攻击（高频接口调用、无验证码、伪造 User-Agent）应被拦截。

性能压测。QPS、响应时间、错误率、CPU/内存水位、Redis/MQ 队列堆积情况。常见目标：商详页 RT < 100ms、下单接口 RT < 500ms、错误率 < 0.1%。

降级与容灾。Redis 挂了走 DB 兜底（但要降低 QPS 上限）；MQ 堆积时下单接口快速失败；秒杀服务故障时只影响秒杀不影响主交易。

公平性。同一时间点的请求是否真正按到达顺序处理；是否存在 IP / 用户层面的不公（少数用户被服务多次）。

秒杀稳定性是大促核心 KPI，一次 P0 故障可能影响品牌信任，测试同学要在正式秒杀前至少做 3 轮全链路压测 + 故障演练。

Q10: 订单状态机怎么测？常见的状态机错误有哪些？

答案：

订单状态机是电商系统的"心脏"，任何状态错乱都会引发用户投诉甚至资损。一个典型订单状态机如下：

测试方法上，状态机测试不是穷举状态对，而是按「合法迁移 + 非法迁移 + 并发迁移」三类组织：

合法迁移。每条箭头对应一条用例，验证迁移成功且副作用正确（库存回滚、优惠回退、积分变化、消息通知）。

非法迁移。每个状态去触发不允许的事件，断言被拒绝。比如「已支付」状态再次支付应幂等；「已取消」订单不应能发货；「已退款」订单不应能再退一次。

并发迁移。两个事件同时到达（如用户点取消的同时支付回调到了），系统必须保证状态机原子推进，不能出现"已支付 + 已取消"双态。一般用乐观锁（订单版本号）或行级悲观锁实现。

常见的状态机 Bug：

回调乱序。支付成功回调和退款回调几乎同时到，没用版本号导致最终状态变成「已支付」（实际应该是「已退款」）。

补偿失效。状态机推进失败后没回滚，库存被扣但订单状态没更新，用户看到"未支付"但商品已没了。

字段冗余。订单状态在多张表里冗余（订单表、支付表、物流表），同步逻辑不严谨导致几张表对不上。

测试时强烈建议引入「订单状态机一致性巡检」脚本，定期扫数据库对比各表状态是否对齐，发现 Bug 早。

三、状态机、售后与多端一致性（4题）

Q11: 退款与售后逆向链路有哪些测试要点？

答案：

售后是电商系统里复杂度最高的逆向链路，业务规则多、外部依赖多、资损风险高。常见的售后类型包括「仅退款」「退货退款」「换货」「部分退款」「整单退款」，每种逆向链路要走的环节都不同。

退款金额计算是测试核心。要验证：

整单退款 = 实付金额（不是商品价，要扣掉运费、优惠分摊）。

部分退款时，优惠按「按比例分摊」原则退回。比如 100 元订单用了 10 元券，只退 1 件商品（占 50 元）时，应退回 50 - 5 = 45 元，并退还该商品对应的 5 元优惠。

退运费规则。卖家责任退运费、买家责任不退、特殊情况按平台规则。

退款时机。支付当天退原路返回、跨天可能涉及银行处理时长、跨境涉及汇率波动。

副作用要全面回滚：

库存。仅退款不回库存（商品还在用户手上）；退货退款必须确认收货后才回库存；部分退款只回退部分。

优惠券。退款金额低于券门槛时券应原路退回；订单使用的限领券退回后用户能否再用。

积分。订单完成时发放的积分，退款后要按比例扣回；如果积分已被用户消费完，要做"负积分"还是"先冻结后扣"。

营销资格。新人首单退款后，用户是否还算"首单"。

测试时除功能用例外，还要做"金额平衡校验脚本"：每天扫订单表 + 退款表 + 资金流水，断言「所有订单实付总额 = 所有支付流水总额 - 退款流水总额」，长期跑这个校验是发现金额计算 Bug 的最有效手段。

Q12: 拆单合单怎么测？跨境履约有哪些特殊场景？

答案：

拆单合单是订单履约阶段的常见操作，但对前端显示、状态机、退款都有连锁影响。

拆单原因常见有：商品来自不同仓库、商家自营 vs 第三方、商品类型不同（普通 vs 生鲜 vs 大件）、物流方式不同。

拆单测试关注点：

何时拆。下单时拆（前端就显示多个子单）还是发货时拆（前端显示一单但物流多包裹）。两种策略对用户体验和后台数据模型影响很大。

价格与优惠分摊。原订单的优惠按金额或商品维度分摊到子单上，要保证子单实付金额加总 = 原订单实付金额（包括运费、税费、优惠）。

子单独立状态。每个子单有自己的物流、签收、售后流程，但用户感知层面可能希望看到"父单进度"。

退款。部分子单退款时，怎么分摊优惠回退、其他子单是否受影响。

合单类似但方向相反，常见于同店铺多商品发货。

跨境履约的特殊场景：

清关。订单需要海关申报，要测身份证号码校验（个人年度限额 26000 元）、商品编码、申报金额（用户实付价、不含优惠还是含优惠各国规则不同）。

汇率。下单时锁价的汇率 vs 实际支付汇率，差额谁承担。

物流路径。境内仓 → 转关 → 境外清关 → 境外配送，每个节点的状态同步、超时处理。

退税与退款。跨境退款是否涉及退税回退、汇率波动差额。

合规。海关申报、个人年度限额追踪、特殊商品禁运（医疗器械、食品、化妆品备案）。

跨境业务往往与国家政策强耦合，建议测试同学维护一份"合规检查清单"，每次政策变更前同步更新。

Q13: 电商多端一致性怎么测？

答案：

电商系统典型多端：iOS APP、Android APP、H5、小程序（微信/支付宝/抖音）、PC Web。同一个用户在不同端的体验必须一致，但又要适配各端能力差异，测试维度繁多。

业务数据一致性。商品价格、库存、上架状态、活动信息在各端必须一致，主要靠后端 API 统一。常见 Bug 是 H5 缓存了旧价格、小程序版本未升级导致 API 响应字段不全。

功能完整性。核心交易能力（搜索、加购、下单、支付、查订单、售后）所有端都要支持；某些能力可能因平台限制有差异，比如微信小程序不能跳第三方支付（必须用微信支付）、抖音小程序对外链有限制。

UI 一致性。设计稿一致但渲染各端差异（字体、间距、暗黑模式适配），属于设计走查范畴。

跨端流转。在 H5 加购，到 APP 看购物车是否同步；APP 下单到一半，切换到小程序能否继续；扫码登录后会话同步。

性能差异。小程序包大小限制、APP 安装包加载、H5 首屏速度，要分别评估。

特殊端能力。NFC 支付、刷脸支付、生物识别只在 APP 上有；分享、群拼团在小程序生态最自然。

测试组织上推荐三种策略：

API 一致性。所有端调用同一套后端 API 时返回应一致，写一套接口测试覆盖所有 API，所有端共享。

跨端冒烟。每次大版本发布跑一套覆盖所有端的核心冒烟用例，确保各端核心链路打通。

各端专项。每个端有自己的特性测试集（如 APP 测设备权限、小程序测授权弹窗、H5 测兼容性），按端独立维护。

实战中常见的多端 Bug：旧版本 APP 调用新 API 字段缺失导致崩溃；H5 在不同浏览器 cookie 行为不一；微信小程序对 storage 大小限制超限报错。

Q14: 缓存与数据库一致性问题怎么测？

答案：

电商系统大量使用 Redis 做商品、库存、用户、营销的缓存，缓存与 DB 不一致会直接导致用户看到错误价格、错误库存，引发投诉甚至资损。

常见一致性模式有：

Cache Aside。读时先查缓存，未命中查 DB 再写缓存；写时先更新 DB 再删除缓存。最常用，但有「写后读延迟」窗口。

Read/Write Through。应用只访问缓存，由缓存代理读写 DB。一致性强但实现复杂。

Write Behind。先写缓存，异步刷 DB。性能好但 DB 落后，故障可能丢数据。

测试时常见的不一致场景：

并发读写。线程 A 查到 DB 旧值，准备写缓存；线程 B 同时更新 DB 并删缓存；A 把旧值写回缓存。结果：缓存里是旧值。测试方法：用脚本制造高并发读写，每次校验缓存与 DB 一致；或借助压测工具引入 sleep 模拟时序。

缓存击穿。热门商品缓存过期瞬间大量请求涌入 DB，要验证有没有用「互斥锁」或「逻辑过期」防击穿。

缓存穿透。请求不存在的商品 ID 一直查 DB，要验证有没有用空值缓存或布隆过滤器。

缓存雪崩。大量缓存同一时刻过期。测试时把缓存清空，看核心接口 QPS 和 DB 压力。

数据更新延迟。商品信息修改后，要验证缓存被刷新或失效，并量化最大延迟（通常要求秒级）。

主从延迟联动。写主库后立即读从库可能读到旧值，再写缓存就把旧值缓存了。要测开「读主库」或延迟读策略。

测试工具上，可以用脚本周期扫描热点数据，对比 Redis 和 MySQL 值是否一致，记录差异时间窗，作为线上巡检的一部分。

四、一致性、风控与大促保障（4题）

Q15: 分布式事务有哪些方案？怎么测？

答案：

电商下单链路跨多个服务（订单、库存、优惠、积分），单一数据库事务搞不定，必须用分布式事务方案。常见方案有：

TCC（Try-Confirm-Cancel）。每个参与方实现三段：Try 预占资源、Confirm 实际提交、Cancel 回滚。测试时要覆盖：所有 Try 成功 → Confirm 成功的快乐路径；某个 Try 失败 → 全部 Cancel；Confirm 阶段部分失败 → 重试直到成功；Cancel 阶段部分失败 → 重试直到全部回滚；幂等性（每个阶段重复调用结果一致）；空回滚（Try 还没执行就被 Cancel）；悬挂（Cancel 已执行后 Try 才到）。

Saga。事务拆成一系列本地事务，每步都有对应的补偿操作，失败时按反向顺序补偿。测试关注：每一步成功的快乐路径；任意一步失败时前面已成功的步骤被正确补偿；补偿动作本身失败时的重试与告警。

本地消息表。本地事务写业务表 + 消息表，后台任务扫描消息表投递到 MQ。测试关注：消息漏发（业务成功但消息表写失败）、消息重复（消费方幂等）、消息顺序（必要时用顺序 MQ）。

测试方法上，分布式事务的核心测试手段是「故障注入」：在不同阶段杀进程、断网、抛异常、超时，断言系统最终一致。可以借助 Chaos Engineering 工具（ChaosBlade、Chaos Mesh）模拟各种故障。

每个核心交易场景都要画出「分布式事务时序图」，把每个参与方、每个阶段、每个失败点都标出来，对应一份用例，长期维护成回归集。

Q16: 黄牛、羊毛党风控测试要做哪些？

答案：

电商营销活动是黄牛羊毛党的主战场，平台每次活动都要平衡"用户体验"和"防作弊"。风控测试核心是验证策略有效性和误伤率。

常见黄牛羊毛手段：

批量注册。用接码平台、临时邮箱注册大量账号薅新人福利。

设备伪造。用群控、改机软件改设备 ID，让一台设备伪装成 N 台。

IP 伪造。用代理 IP 池切换地址，规避 IP 限制。

脚本下单。模拟 APP 协议直接调接口，跳过前端反爬。

身份盗用。用买卖来的真实身份信息注册账号。

风控测试维度：

设备指纹。生成设备唯一 ID 的算法要稳定，同一设备多次启动 ID 一致；改机软件下要能识别异常。测试时用真机做正常行为，用模拟器和改机工具做异常行为，看风控识别率。

行为分析。下单速度（人眼无法 200ms 完成下单）、滑动轨迹、点击模式都是判断真人 vs 机器的依据。

风控规则。常见规则如"24 小时内同一设备下单 > 10 单告警""同一收货地址 3 天内 > 5 单冻结"，要按规则逐条覆盖正向（不命中）、刚好命中、超过命中。

灰名单与黑名单。命中规则后用户进入灰名单（部分能力受限）或黑名单（完全封禁），测试这些状态下用户的浏览、加购、下单、支付各环节体验是否符合策略。

误伤率。真实用户被误判为黄牛的比例（KPI），要建一组真人用例做"白盒"测试，统计误伤率，过高时反向调优策略。

风控测试和一般功能测试最大差异是：黑产手段在变，规则也在变，需要建立持续对抗的测试闭环（攻防演练、定期红蓝对抗）。

Q17: 大促备战测试有哪些专项？

答案：

大促（双 11、618、年货节）是电商团队一年里最关键的几次"考试"，从备战到收官通常持续 1~2 个月，测试要做的事情远比平时多。

容量评估与压测。先按业务预估各接口峰值 QPS（通常基于上一届数据 × 增长系数），分接口、分链路做压测，验证系统能否扛住目标流量。重点链路有：商品搜索、商详、加购、下单、支付、订单查询。压测分单接口、混合场景、全链路三种，最重要的是全链路压测（在线上影子库跑真实流量）。

降级演练。预先定义降级开关清单（搜索降级到关键词匹配、推荐降级到热销榜、详情页降级到静态化、个性化功能临时下线），演练时手动开启每个开关，验证主链路依然可用、用户感知可接受。

熔断与限流。每个核心接口都要有限流配置（按 QPS / 按用户级别 / 按 API），熔断阈值（错误率 / 慢调用率）。测试时压到阈值看熔断是否触发、错误返回是否对前端友好。

预案演练。常见预案如"Redis 集群故障""数据库主库故障""第三方支付故障"，每个预案要有详细 SOP（标准操作流程），定期演练让团队熟练操作。

数据预热。商品缓存、活动缓存、用户优惠券都要在大促开始前预热到 Redis，避免开抢瞬间击穿。测试要验证预热脚本的正确性、覆盖率、过期时间策略。

监控告警。所有核心指标（QPS、RT、错误率、库存余量、订单量、资损金额）都要有大屏、告警规则、值班同学。测试时手动构造异常看告警是否触发、是否能到具体负责人。

业务回归。促销规则、活动配置、优惠券规则、风控规则在大促前会有大量调整，需要安排专项回归，避免老用例不覆盖新规则。

复盘。每次大促后做技术复盘，把这次发现的问题、应急处理、性能数据沉淀下来，下一届做更好。这是经验积累的关键环节。

Q18: 主从延迟会带来哪些电商场景下的典型问题？怎么测？

答案：

电商系统普遍用 MySQL 主从架构（读写分离），主库写、从库读，主从延迟（Replication Lag）在大促时容易飙到几秒甚至几十秒。延迟带来的业务问题：

下单后查不到。用户支付完成跳转订单页，订单页查从库，如果延迟超过几秒会显示"订单不存在"，用户大概率会重复支付。

库存超卖。下单服务读从库判断库存（看似还有），实际主库已经被其他订单扣完，写入时才发现负库存。这是最危险的延迟问题。

优惠重复使用。读从库判断券未使用，实际主库已经标为已用；并发场景下用户的一张券可能用了两次。

价格计算偏差。读从库的商品价、活动价是旧值，写入时按旧价生成订单，但用户付款是按新价。

排行榜与数据看板。后台运营看的销量、库存数据滞后于真实业务，导致决策偏差。

测试方法：

构造延迟。压测时主动给从库注入延迟（用 pt-slave-delay 或 MySQL CHANGE MASTER TO MASTER_DELAY=N），观察各业务接口表现。

主从一致性巡检。写一组接口测试，写主后立即读从对比，统计延迟分布。

读主策略验证。关键路径（下单、支付、库存）应配置"读主库"，测试时把从库停掉看这些路径是否仍可用。

事务一致性。同一事务内读写应在同一连接，避免读旧数据。

延迟降级策略。延迟超过阈值时自动切换读主或降级缓存，测试这套策略的触发逻辑和告警机制。

实战中除了功能测试，还要在监控系统里设置主从延迟告警（一般 > 1 秒就告警），结合慢 SQL 监控找出可能引发主从延迟的烂 SQL，提前优化。