多级确认必须自实现UI层，禁用原生confirm链式调用；应使用fixed模态框、状态管理、Promise封装、焦点控制与可访问性支持，并通过requestId幂等、AbortController、实时数据拉取和防重复提交保障操作一致性。
点击按钮后弹出多级确认对话框（原生 alert / confirm 不支持）
浏览器原生的 confirm() 只能单层、单是/否，没法做“确定→再确认→执行”这种流程。真要多级确认，必须自己实现 UI 层，不能依赖原生弹窗。
常见错误是试图链式调用 confirm()，比如：
if (confirm('第一步？')) { if (confirm('第二步？')) { ... } }——这会导致对话框堆叠、焦点混乱、无法取消上一级，且在 Safari 等浏览器中可能被拦截或行为异常。
实操建议：
- 用
div+position: fixed模拟模态框，配合aria-modal="true"和焦点管理（focus()到第一个可交互元素）保证可访问性 - 每级确认状态用独立变量或状态对象管理，例如
step: 'verify' | 'dangerous' | 'executing' - 禁用背景滚动：打开时给
<body>加style="overflow: hidden;"，关闭时恢复
用 Promise 封装多级确认逻辑，让调用像同步一样自然
把多级流程包装成返回 Promise 的函数，调用方可以用 await 逐级等待，代码扁平、易读、可中断。
立即学习“前端免费学习笔记（深入）”；
示例结构（不依赖框架）：
function multiConfirm(options) {
return new Promise((resolve) => {
// 渲染第一级 DOM，绑定「继续」按钮事件
document.getElementById('confirm-btn').onclick = () => {
// 显示第二级，更新文案和按钮
document.getElementById('step2').style.display = 'block';
document.getElementById('step2-btn').onclick = () => {
resolve({ confirmed: true, step: 'final' });
};
};
});
}
使用时：
const result = await multiConfirm({ title: '删除项目', danger: true });比嵌套回调或一堆 if 判断清晰得多。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
注意点：
- 必须手动处理用户点击遮罩层、按
Esc键等取消路径，并调用resolve({ confirmed: false }) - 不要在
Promise外部保留对 DOM 节点的强引用，避免内存泄漏 - 如果涉及异步校验（如检查资源是否正在使用），把
fetch放在对应步骤内，而不是提前发起
移动端适配与触摸反馈容易被忽略
桌面端 hover 效果、鼠标右键禁用等，在手机上完全无效；但很多人照搬 PC 方案，导致按钮点不动、确认区域太小、连续点击无反馈。
关键动作：
- 确认按钮最小尺寸设为
44px × 44px（iOS 最小触控单位），用min-height+padding保证 - 加
touch-action: manipulation防止 300ms 延迟 - 点击后立即禁用按钮并加 loading 状态（哪怕只是改文字为「执行中…」），否则用户可能连点多次触发重复操作
- 避免在多级确认中使用
transform: scale()动画，部分安卓 WebView 渲染异常导致按钮失灵
防重复提交和状态竞态是核心难点
用户狂点「确认」、「再确认」、「执行」，或者网络慢导致多个请求并发，后端收到重复指令，这是多级确认最常翻车的地方。
不能只靠前端按钮置灰——刷新页面或绕过 JS 就失效。必须：
- 在最后一步发起请求前，生成唯一
requestId（如Date.now() + Math.random()），附在请求 body 中 - 后端对同一
requestId做幂等判断（Redis 记录已处理 ID，TTL 设为 5 分钟） - 前端在
fetch后统一加AbortController，防止用户快速切换步骤导致旧请求还在跑 - 如果某级确认依赖实时数据（如「当前有 3 个用户在线」），应在点击该级按钮时重新拉取，而不是复用初始加载的数据
真正麻烦的不是怎么弹窗，而是确保「用户看到的确认内容」和「最终执行的动作」严格一致——中间任何一环状态没锁住，就可能删错东西、发错邮件、关错服务。
