优先用 setinterval，简单可靠；requestanimationframe 适合动画帧同步但易因页面失焦导致跳秒，倒计时精度要求不高，且需每次用 date.now() 重算剩余时间避免累积误差。
倒计时逻辑用 setInterval 还是 requestAnimationFrame？
优先用 setInterval，简单可靠；requestAnimationFrame 适合动画帧同步场景，但倒计时对精度要求不高，反而容易因页面失焦、后台运行导致跳秒或卡顿。
关键点：别直接用 setTimeout 递归——累积误差大，10分钟后可能差2–3秒。
实操建议：
• 启动时用 Date.now() 记录目标时间戳（比如抢购开始时间），每次轮询都重新计算剩余毫秒数，不依赖上一次的“减1000”
• 每秒执行一次，间隔设为 1000，不要设 997 或 1005 自作聪明
• 加个防抖：如果某次执行延迟超 200ms，跳过本次更新，避免连刷造成视觉抖动
new Date() 解析时间字符串在不同浏览器表现不一致？
是的，比如 "2024-10-25 20:00:00" 在 Safari 会返回 Invalid Date，因为非标准格式。必须转成 ISO 格式或手动解析。
实操建议：
• 后端返回时间统一用 ISO 8601 字符串，如 "2024-10-25T20:00:00+08:00"，new Date() 能安全解析
• 如果只能拿到 "2024-10-25 20:00:00"，用正则拆分再构造： new Date(...timeStr.match(/(\d+)-(\d+)-(\d+) (\d+):(\d+):(\d+)/).slice(1))
• 别信 Date.parse() 对空格分隔格式的支持——它在旧版 Chrome 和所有 IE 中不可靠
倒计时结束时 DOM 更新和接口调用怎么同步？
常见错误是倒计时一停就立刻发请求，结果后端还没开闸，返回 "Not started yet"。必须把「时间到达」和「业务开关」解耦。
实操建议：
• 倒计时到 0 后，禁用按钮并显示“立即抢购”，但不自动提交；用户点击才触发请求
• 接口响应要带状态字段，比如 { status: "open", stock: 99 }，前端据此决定是否允许下单
• 加个兜底检查：提交前再读一次服务端时间（可缓存 10 秒），若服务端时间仍
CSS 动画让倒计时数字“翻页”效果，会影响性能或渲染错位？
纯 CSS 的 transform: translateY 翻页动画在低端安卓机上容易掉帧，且数字宽度不一致（比如 “1” 和 “8”）会导致左右晃动。
实操建议：
• 用等宽字体：CSS 加 font-family: 'Courier New', monospace
• 每个数字用独立 <span></span> 包裹，设置固定宽高 + overflow: hidden
• 动画只作用于内部数字列表的 top 位移，避免触发布局重排
• 更稳妥的做法：不用动画，用 opacity 交叉淡入淡出，兼容性好、CPU 占用低
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
