倒计时需用状态变量isCounting与disabled属性双重控制，启动前清除旧定时器，结束时重置状态；表单提交须校验isCounting为false且输入非空；移动端需时间戳校准并监听focus/blur；后端时间验证是最终安全防线。
倒计时结束前禁止重复点击发送
用户点一次“获取验证码”后立刻再点，会导致后端频繁发短信、前端状态错乱。关键不是禁用按钮本身，而是要靠状态变量 + 按钮属性双重控制。
常见错误是只改 disabled 属性但没清空定时器，或倒计时未归零就重置导致逻辑混乱。
- 用一个布尔变量（如
isCounting）标记当前是否处于倒计时中 - 点击时先判断
if (isCounting) return，再设置isCounting = true - 务必在倒计时结束回调里重置
isCounting = false，否则后续点击永远无效 - 按钮的
disabled属性建议同步更新，提升可访问性（screen reader 可感知）
setInterval 倒计时必须手动清理
不清理会导致内存泄漏，且多个倒计时叠加运行——比如用户快速点 3 次，就会同时跑 3 个 setInterval，界面显示错乱，时间跳变。
正确做法是每次启动新倒计时前，先清除旧的：
立即学习“前端免费学习笔记（深入）”；
let timerId = null;
<p>function startCountdown() {
if (timerId) clearInterval(timerId);
let count = 60;
const btn = document.getElementById('send-code');
btn.disabled = true;</p><p>timerId = setInterval(() => {
count--;
btn.textContent = <code>${count}s 后重发</code>;
if (count <= 0) {
clearInterval(timerId);
timerId = null;
btn.disabled = false;
btn.textContent = '获取验证码';
}
}, 1000);
}表单提交时校验倒计时是否真正完成
仅靠前端倒计时 UI 不足以保证安全性。用户可能绕过 JS、篡改 DOM 或直接调用 submit()，所以后端必须校验验证码是否在有效期内（如 5 分钟），而前端也应做基础拦截。
推荐在表单 submit 事件中检查两个条件：
- 输入框是否有值（
input.value.trim() !== ''） - 倒计时是否已结束（即
isCounting === false，且按钮已恢复可点击状态）
注意：不要依赖倒计时数值是否为 0 来判断——因为用户可能手动把 textContent 改成 “0s”，实际 isCounting 还是 true。状态变量才是唯一可信依据。
移动端 Safari 和微信 WebView 的兼容细节
部分 iOS 微信内嵌浏览器会冻结页面后台定时器（即使页面没切走），导致倒计时暂停或跳秒；还有些机型在键盘弹起后触发页面重排，意外重置定时器。
缓解策略：
- 避免用
setTimeout递归模拟倒计时（易累积误差），坚持用setInterval+ 时间戳校准 - 在倒计时启动时记录开始时间
startTime = Date.now()，每次 tick 用Math.floor((startTime + 60000 - Date.now()) / 1000)计算剩余秒数，抗暂停 - 监听
blur和focus事件，在页面失焦时暂停倒计时，聚焦时按剩余时间续上（需额外存状态）
真正在生产环境用，倒计时有效性最终靠后端时间戳比对，前端只是体验层防护——这点容易被忽略，但很关键。
