校招面试里，“100 件库存同时来了 1 万人，你怎么测试”几乎是一道经典题。很多同学会立刻列：功能、性能、安全、兼容、弱网，再补一句 JMeter 模拟 1 万并发。
看起来全面，却容易被追问两句就断掉：这一万人是同时连接还是一秒内到达？下单成功以接口 200、订单落库还是支付成功为准？未支付库存多久释放？
第一步不是列点，而是确认系统承诺
你可以先问四件事：是否一人一单；库存在哪个阶段扣减；订单创建和支付是否异步；超时与重复请求怎样处理。
这几问能把“测秒杀”变成明确状态机：可售 → 锁定 → 已售，失败或超时则从锁定回到可售。随后才能写出真正重要的不变量：库存不能为负；成功订单不能超过 100；同一用户不能重复占用；可售、锁定、已售三者之和守恒。
一段并发脚本，只负责制造条件
下面用 500 个模拟用户演示。每个请求带稳定幂等键，故意让部分用户重复提交。脚本只收集请求证据，最终结论必须回到数据库和库存状态：
import asyncio, uuid, httpx
async def buy(client, user_id, duplicate=False):
key = f"sale-20260905-{user_id}"
payload = {"sku":"PHONE-X", "user_id":user_id}
async def once():
r = await client.post("http://sut/seckill", json=payload,
headers={"Idempotency-Key": key})
return r.status_code, r.json()
if duplicate:
return await asyncio.gather(once(), once())
return [await once()]
async def run_burst(users=500):
limits = httpx.Limits(max_connections=600)
async with httpx.AsyncClient(timeout=10, limits=limits) as client:
tasks = [buy(client, f"u-{i}", duplicate=(i % 20 == 0))
for i in range(users)]
return await asyncio.gather(*tasks)
为什么不是直接写 1 万？因为面试里要说明负载模型来自容量目标，而不是数字越大越专业。单机脚本能不能稳定发出 1 万并发、连接池和压测机是否先成瓶颈，都要校准。正式压测更应按“到达率、峰值持续时间、地域和失败重试”建模。
压完之后，要核对四本账
第一本是请求账：谁发了几次、用了什么幂等键。第二本是订单账：成功订单数量和用户唯一性。第三本是库存账：可售、锁定、已售是否守恒。第四本是资金账：支付迟到、关单、退款是否闭环。
def assert_final_state(db, initial_stock=100):
orders = db.query("SELECT user_id, status FROM orders WHERE sale_id='20260905'")
paid = [o for o in orders if o.status == "PAID"]
assert len({o.user_id for o in orders}) == len(orders)
assert len(paid) <= initial_stock
stock = db.one("SELECT available, locked, sold FROM stock WHERE sku='PHONE-X'")
assert min(stock.available, stock.locked, stock.sold) >= 0
assert stock.available + stock.locked + stock.sold == initial_stock
再补三个故障，答案就有工程味了
在库存锁定成功、订单消息发送前杀进程；支付回调重复三次；消费者处理成功但 ACK 丢失。每个故障都要说明预期状态、补偿触发条件和最终收敛时间。
最后再谈性能：关注成功请求的 P95/P99、限流是否明确、失败是否快速、数据库锁等待与消息积压，而不是只报一个峰值 QPS。
校招题不是让你在五分钟里设计完整秒杀平台。面试官真正判断的是：面对模糊需求，你能否先问清口径，抓住最关键的不变量，再用代码和数据形成证据。这种回答方式，换到订单、优惠券、抢票和库存系统同样成立。
