根本原因是未在事件触发瞬间同步设置 button.disabled = true 或使用 type="submit" 导致表单原生提交中断 JS 执行流；实操需改 type="button"、点击即禁用并更新文案、存过期时间戳至 localStorage 以支持跨刷新倒计时，并配合后端限流与错误响应动态调整。
点击后按钮没禁用或禁用失效
根本原因是没在事件触发瞬间同步设置 button.disabled = true，或用了 type="submit" 导致表单原生提交中断 JS 执行流。浏览器可能还没来得及更新 DOM，页面就跳走了。
实操建议：
立即学习“前端免费学习笔记（深入）”；
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 把按钮改为
type="button"，用form.submit()或fetch显式控制提交时机 - 点击回调第一行就写
btn.disabled = true，别等异步返回 - 禁用的同时改
btn.textContent（比如变成“60s”），提供视觉反馈 - 别依赖 CSS 的
pointer-events: none单独禁用——它不阻止键盘回车、也不影响disabled属性语义
倒计时中刷新页面，按钮又变可点了
因为内存里的 countdownTimer 和 secondsLeft 全丢了，localStorage 里又没存过期时间戳，页面一刷就回到初始状态。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 禁用开始时，立刻往
localStorage写一个键，值是Date.now() + 60000（比如 60 秒后过期） - 页面加载时，读这个时间戳，和
Date.now()比较：若未过期，就直接禁用按钮，并算出剩余秒数重新启动setInterval - 别存布尔值（如
"disabled": true），存时间戳才能支持跨刷新的精确倒计时 - 每次
setInterval回调里都检查if (remaining ，而不是 <code>=== 0，防 JS 延迟导致卡在 “1s”
倒计时结束但按钮没恢复，或点了两次才恢复
常见于 clearInterval 后忘记重置 button.disabled，或者多个定时器 ID 混用（比如全局变量 timerId 被覆盖），导致清除的不是当前那个。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 清除定时器后，必须紧跟着执行
btn.disabled = false和btn.textContent = "获取验证码" - 把定时器 ID 存在按钮元素上，比如
btn._timerId = setInterval(...)，避免作用域污染 - 倒计时逻辑用闭包或模块封装，别让多个按钮共享同一个
countdownTimer变量 - 恢复按钮前加个兜底判断：
if (Date.now() >= expireTime) { ... }，防止 localStorage 时间被手动篡改后逻辑错乱
后端已限流，前端倒计时还有必要吗
有必要。倒计时不是为了替代后端防护，而是防止用户因无反馈而狂点——那会放大失败请求、触发更激进的限流、甚至拖垮接口。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 前端倒计时只做体验层封锁：禁用按钮、更新文案、配合
pointer-events: none和opacity视觉降级 - 后端必须校验请求时间戳或 token 有效性，不能信任前端传来的任何“我已禁用”的标识
- 如果后端返回 429（Too Many Requests），前端应立即拉长本地倒计时（比如从 60s → 300s），并提示“操作太频繁，请稍后再试”
- 别在点击瞬间就启动倒计时，等
fetch成功响应后再开——否则请求失败了，用户却以为发出去了
clearInterval 后是否同步更新 DOM 属性，往往就是按钮卡死或误恢复的分水岭。 
