拼团页面核心是状态同步、倒计时一致性、库存实时反馈；必须后端驱动状态机，用服务端时间戳+客户端校准倒计时，库存与按钮状态须严格联动后端真实余量。
拼团页面不是堆砌动画和按钮就行，核心是状态同步、倒计时一致性、库存实时反馈这三件事没处理好，用户点完“开团”发现参团失败，或者倒计时在不同设备上差十几秒，活动信任感就崩了。
拼团状态机必须用后端驱动，别信前端 localStorage
用户看到的「已成团」「拼团中」「已过期」不能靠 localStorage 或 sessionStorage 存状态——缓存可能未更新、多标签页不一致、用户清缓存就丢状态。真实拼团状态只应由后端接口返回，且每次关键操作（开团、参团、支付成功）后必须重新拉取最新状态。
- 每次进入页面或切 Tab 后，主动调用
/api/group/status?group_id=xxx获取当前团状态和剩余时间 - 不要在前端写类似
if (status === 'success') { showSuccess() }这样的硬编码分支，而应把所有状态映射为后端返回的status字段值（如"pending"、"success"、"expired"、"closed"） - 特别注意：支付回调成功后，前端不能只弹个 toast 就完事，必须立刻触发状态刷新，否则用户刷新页面可能仍显示「拼团中」
倒计时必须用服务端时间戳 + 客户端校准，别直接 new Date()
直接用 new Date() 算剩余时间，用户手机时间快 3 分钟，倒计时就比别人早结束；时间慢 5 分钟，又会出现「明明该结束了还在倒数」。正确做法是后端返回一个绝对截止时间戳（如 end_timestamp: 1717023600000），前端用本地时间与之对比，并每 30 秒用 /api/time 校准一次时钟偏移。
- 首次加载时，请求
/api/time得到服务器当前毫秒时间server_time，与Date.now()做差，得到本地偏移量offset = server_time - Date.now() - 倒计时计算用：
remaining = group.end_timestamp - (Date.now() + offset) - 每 30 秒再调一次
/api/time更新offset，避免长时间运行后误差累积超过 1 秒 - 不要用
setInterval(fn, 1000)每秒执行——它不精准，建议用requestAnimationFrame驱动渲染，时间逻辑仍走系统时间戳计算
库存显示和按钮禁用必须联动后端真实余量，防超卖关键在这一步
「仅剩 2 个名额」这种提示如果只是前端减数字，用户绕过 JS 或重复点击就能超发。真正有效的库存控制在后端，但前端必须做到视觉和交互层面严格同步。
立即学习“前端免费学习笔记（深入）”；
- 按钮文案和禁用状态必须由后端返回的
stock和joined_count、max_size共同决定，例如：if (joined_count >= max_size || stock - 参团接口
POST /api/group/join必须返回明确结果：{ "code": 0, "msg": "ok", "stock": 1 }或{"code": 400, "msg": "库存不足"}，前端收到后立即更新 UI，而不是等下一次轮询 - 不要做「乐观更新」：比如先扣前端库存再发请求——这会导致用户看到「已抢光」但其实刚抢到，体验割裂
- 极端情况（如网络重试）下，按钮点击后需设 loading 并置灰，防止重复提交；接口返回前不恢复可点击状态
拼团最易被忽略的是「跨设备状态漂移」：用户用微信开团，用 Safari 参团，两个页面用的不是同一套缓存和定时器，倒计时和库存很容易对不上。解决它不靠加功能，靠砍掉所有前端单点状态依赖，让每个像素都听命于后端一次响应。
