定时器与用户输入事件并发易致状态错乱、重复提交等问题，核心是分离读写职责、用状态标记或Promise缓存控制入口、禁用按钮并暂停定时器，再交由响应式系统统一更新UI。
定时器和用户输入事件同时触发时，容易出现状态错乱、重复提交、UI响应卡顿或数据覆盖等问题。关键不是“阻止”哪一方，而是让两者在共享资源或操作同一对象时互不干扰。
明确事件边界与执行上下文
很多冲突源于默认把定时器回调和输入事件回调当作“同等级”的同步逻辑来处理。实际上它们的触发时机、预期耗时、失败容忍度都不同。
- 用户输入（如按钮点击、表单提交）应具备即时反馈和可中断性；定时器任务则更偏向后台周期性维护，比如轮询、缓存刷新、倒计时更新
- 避免在输入事件中直接修改被定时器持续读写的变量（例如一个全局倒计时秒数），改用状态机或不可变快照方式传递值
- 前端常见做法：点击后禁用按钮并显示加载态，同时暂停相关定时器（clearInterval 或 stop()），任务完成后再恢复
加锁或标记控制关键操作入口
当必须由定时器和用户操作共同触发同一业务动作（如“立即同步数据”既可手动点，也可每5分钟自动跑），需限制同一时刻只允许一个入口执行。
- 用布尔标记位控制：定义 isSyncing = false，任一入口开始前先判断，为 false 才设 true 并执行，完成后重置
- 更稳妥可用 Promise 缓存：首次调用返回 Promise，后续调用直接复用该 Promise，避免并发请求
- 后端接口层面配合幂等设计（如带唯一请求 ID 或时间戳签名），即使前端没控住，服务端也能拒绝重复提交
分离读写职责，避免共享状态竞争
冲突常发生在多个来源同时读写同一个 DOM 元素、React state、Vuex store 或 localStorage key 上。
- 定时器只负责“推新数据”，不直接操作 UI；输入事件只负责“发指令”，不主动刷新视图
- 统一交由响应式系统接管：例如 Vue 的 computed、React 的 useEffect + useState，让 UI 基于单一数据源自动更新
- 对频繁更新的状态（如实时计数器），使用防抖或节流控制更新频率，避免输入事件和定时器来回刷屏
前端示例：禁用按钮 + 暂停定时器
以“手动刷新列表 + 每10秒自动拉取”为例：
- 点击刷新按钮 → clearInterval(autoFetchTimer)，按钮置灰，发起请求
- 请求成功后 → 重置 autoFetchTimer，按钮恢复可用
- 若定时器正在运行中用户又点击 → 忽略本次点击，或弹出提示“正在自动刷新中”
