倒计时按钮的核心逻辑是禁用+文本动态更新：点击后立即禁用按钮、启动setInterval每秒更新文案，倒计时归零时清除定时器并恢复按钮状态；需配合手机号校验、请求成功后启动、服务端频率限制及唯一标识绑定。
倒计时按钮的核心逻辑是禁用 + 文本动态更新
关键不是“做个按钮”，而是让按钮在点击后自动进入不可点击状态，并每秒刷新显示剩余秒数。原生 disabled 属性配合 setInterval 就够用，不需要框架或第三方库。
常见错误是只改文字但没禁用按钮，导致用户反复点击触发多次请求；或者倒计时结束后没恢复按钮状态和初始文案。
- 点击后立即设
button.disabled = true，同时记录开始时间或剩余秒数 - 用
setInterval每 1000ms 更新一次button.textContent - 倒计时归零时必须手动清除定时器（
clearInterval），并重置disabled和文案 - 别用
setTimeout递归模拟——容易因 JS 执行延迟导致倒计时不准确
HTML 结构要预留可操作的标识符
不要靠 class 或文本内容定位按钮，直接用 id 或 data-* 属性绑定行为。否则后续加多个验证码按钮时会互相干扰。
示例结构：
立即学习“前端免费学习笔记（深入）”；
<button id="send-code-btn" data-phone="#phone-input">发送验证码</button>
这样 JS 里就能精准获取：document.getElementById('send-code-btn')，再通过 dataset.phone 找到对应手机号输入框做校验。
Html To Pdf
下载
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
- 避免写
<button class="btn send">然后用document.querySelector('.send')—— 页面一有其他“send”类就挂了 - 如果页面有多个验证码按钮，每个都该有唯一
id，或统一用data-action="send-code"配合事件委托 - 不要把倒计时逻辑硬编码进 HTML 的
onclick属性里，不利于维护和测试
发送前必须校验手机号格式，否则倒计时白跑
用户点按钮后才开始倒计时，但网络请求可能失败。如果没校验就直接倒计时，结果验证码发不出去，用户只能干等 60 秒——体验极差。
正确顺序是：点击 → 校验手机号 → 校验通过才发请求 → 请求成功才启动倒计时。
- 基础校验用正则：
/^1[3-9]\d{9}$/（国内手机号），别只 check 是否为空 - 发请求用
fetch或XMLHttpRequest，并在.then()里启动倒计时，.catch()里提示错误并恢复按钮 - 倒计时期间若用户刷新页面，按钮状态不会自动恢复——这是正常现象，无需“记住倒计时状态”，反而增加复杂度
- 服务端必须对同一手机号做频率限制（如 60 秒内仅限 1 次），前端校验只是第一道防线
60 秒倒计时的常见坑：时间不准、重复启动、没清理定时器
看似简单，但实际线上最容易出问题的就是这一块。90% 的“倒计时跳秒不准”或“点两次变成 118 秒”都源于没管好定时器引用。
正确做法是把 intervalId 存在闭包或按钮的 dataset 里，确保每次只存在一个活跃定时器：
let timerId = null;<br>button.addEventListener('click', () => {<br> if (timerId) return; // 防重复触发<br> // ... 发送请求<br> timerId = setInterval(() => {<br> seconds--;<br> button.textContent = `${seconds}秒后重发`;<br> if (seconds <= 0) {<br> clearInterval(timerId);<br> timerId = null;<br> button.disabled = false;<br> button.textContent = '发送验证码';<br> }<br> }, 1000);<br>});- 千万别在每次点击都新建一个
setInterval而不存引用——内存泄漏+逻辑错乱 - 别用
Date.now()做倒计时依据，设备时间被手动修改会导致异常（比如用户调快系统时间，倒计时瞬间归零） - 移动端要注意：页面切到后台时，
setInterval可能被浏览器节流（尤其 iOS Safari），所以服务端必须承担最终校验责任
倒计时本身不难，难的是和表单校验、网络请求、用户中断（比如点完又输错手机号）、多实例共存这些现实场景咬合上。真正卡住人的往往不是怎么写 setInterval，而是没想清楚“什么时候该停、谁来负责恢复、失败了怎么兜底”。
