Bootstrap仅是UI框架，不解决秒杀逻辑；需服务端对齐时间戳、JS层防重复提交、关键节点更新库存、后端必须实现Redis原子扣减与限流。
Bootstrap 本身不提供秒杀逻辑，它只是 UI 框架；直接用 Bootstrap 做秒杀页容易忽略时间同步、按钮防重、库存一致性等关键问题，结果页面看着漂亮，一开抢就乱。
秒杀倒计时不准？别用 setInterval 算本地时间
用户本地时间可能快或慢几分钟，单纯靠 new Date() + setInterval 倒计时会导致不同人看到的“开始时间”不一致，甚至有人提前触发抢购。
- 必须从服务端接口获取标准开始时间戳（如
/api/seckill/info返回startAt: 1717027200000） - 前端用这个时间戳计算剩余毫秒数，再用
setInterval每秒更新 DOM，但每次都要和服务器时间对齐（可每 30 秒重新拉一次） - 避免用
moment().diff()这类依赖本地时区的计算，统一用new Date(serverTimestamp).getTime()
按钮点击没反应或重复提交？Bootstrap 的 disabled 不够用
Bootstrap 的 btn disabled 只禁用样式，但用户快速双击或调试工具里手动触发 click，仍可能绕过。
- 在 JS 中首次点击后立即设
button.disabled = true，并移除click监听器或加锁变量（如let isSubmitting = false） - 请求发出后，不要等响应才禁用——秒杀场景下，「发出去」比「收到成功」更关键，失败由后端幂等控制
- 别用
data-bs-toggle或data-bs-target绑定抢购逻辑，它们是为折叠/模态框设计的，和业务逻辑混在一起难调试
库存显示实时变？别靠前端轮询撑场面
用 setInterval(() => axios.get('/api/seckill/stock'), 1000) 看似实时，实际并发高时接口压垮、延迟飙升，用户看到的库存可能是 2 秒前的。
- 库存数字只在关键节点更新：活动开始前、用户点击抢购后、接口返回成功/失败时
- 后端需提供带版本号或时间戳的库存响应（如
{ stock: 3, updatedAt: "2024-05-30T08:12:45Z" }），前端只当它“可信快照”，不盲目刷新 - Bootstrap 的
badge bg-danger或text-danger可用于视觉提示，但颜色变化不能替代数据准确性
最常被跳过的其实是服务端限流和 Redis 库存扣减原子性——前端做得再顺滑，后端没做 DECR + GET 校验，或者没加分布式锁，页面上“抢到了”三个字，实际订单表里根本没插入。
