倒计时结束前按钮必须设 disabled 以确保功能与语义正确，避免仅用 CSS 模拟；推荐 setTimeout 递归实现计时，基于当前时间动态计算剩余毫秒数，提升准确性。
倒计时结束前按钮必须禁用，但禁用后样式和语义要合理
直接设 disabled 是最稳妥的做法，但很多人只加样式（比如灰色+opacity），没真正禁用，导致用户仍能点击触发购买逻辑。浏览器原生 disabled 会阻止默认事件、表单提交和焦点进入，且对屏幕阅读器友好——这点常被忽略。
实操建议：
- 初始状态就给按钮加上
disabled和 class（如btn--locked），避免 JS 加载延迟导致可点 - 不要仅靠 CSS 的
pointer-events: none模拟禁用，它不阻止键盘回车或辅助技术操作 - 解锁时务必同时移除
disabled和对应 class，别只改样式 - 若按钮是
<button>，disabled会自动灰掉；若是<a>或自定义组件，需额外处理语义（推荐换为<button>）
倒计时用 setInterval 还是 setTimeout 递归？
用 setInterval 看似简单，但容易因 JS 主线程阻塞（如长任务、重绘卡顿）导致计时不准确，尤其在页面后台运行或低性能设备上，可能跳秒甚至漏秒。更可靠的是用 setTimeout 递归调用，每次基于当前时间重新计算剩余毫秒数。
示例核心逻辑：
立即学习“前端免费学习笔记（深入）”；
function startCountdown(endTime) {
const tick = () => {
const remain = Math.max(0, endTime - Date.now());
if (remain <= 0) {
unlockButton();
return;
}
updateDisplay(remain);
setTimeout(tick, Math.min(1000, remain % 1000 + 1));
};
tick();
}关键点：
Html To Pdf
下载
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
-
endTime必须是服务端下发的绝对时间戳（非相对秒数），避免客户端时间被篡改或误差累积 - 每次
setTimeout延迟取remain % 1000 + 1，确保下一帧在整秒前触发，减少跳秒感 - 不用
setInterval(fn, 1000)，它不管上次执行是否完成，易堆积或错乱
解锁按钮时，如何防止重复点击或绕过前端限制？
前端解锁只是体验优化，后端必须校验时间有效性。常见错误是只校验请求到达时间，而没比对商品抢购窗口的起止时间戳。
实操要点：
- 按钮解锁瞬间，立即绑定一次性的点击 handler，并在发送请求后立刻置空该 handler（防连点）
- 请求 body 中必须携带原始
startTime和endTime，后端据此验证该次请求是否落在合法窗口内 - 不要依赖前端传来的“已解锁”状态，后端一律按时间戳判断，哪怕按钮被手动 hack 启用
- 接口返回
403 Forbidden或明确错误码（如{ code: 4001, msg: "抢购未开始" }），前端据此恢复按钮锁定态
移动端 Safari 和旧版 Android 浏览器的时间精度问题
部分 iOS 版本（尤其是 Safari 14.5–15.4）会限制后台标签页的 Date.now() 和 setTimeout 精度，导致倒计时暂停或跳变。这不是 bug，而是系统级节电策略。
应对方式：
- 不依赖连续倒计时动画，优先保证“解锁时刻准确”：用服务端时间戳做最终判断，倒计时显示只是提示
- 监听
visibilitychange事件，在页面切回前台时立即校准剩余时间 - 避免在倒计时函数里做复杂计算或 DOM 批量操作，减少主线程压力
- 测试时务必真机打开 Safari 后台再切回，模拟真实场景
实际中，最易被忽略的是服务端时间与客户端时间的偏差处理——哪怕只差 2 秒，也可能让抢购失败或提前解锁。别信 new Date().getTime() + 60000 这种本地推算。
