应使用自定义模态框+localStorage实现“不再提示”，而非改造原生alert/confirm；需规避confirm被拦截风险，慎用于高危操作，并补充手动清理localStorage后的回退提示。
原生 alert() 无法加“不再提示”勾选框
浏览器原生的 alert()、confirm()、prompt() 都是阻塞式系统级弹窗，DOM 不可访问、无输入控件支持。你没法往里面插 <input type="checkbox">，也没法监听勾选状态——它连返回值都只提供布尔（confirm）或字符串（prompt），没有结构化数据通道。
用自定义模态框 + localStorage 实现“不再提示”逻辑
真正可行的做法是：自己写一个轻量 HTML 模态框，配合勾选项和持久化存储。关键不是“把勾选框塞进警告框”，而是“让用户选一次，之后跳过整个确认流程”。
- 用
<div class="modal"> 搭建非阻塞弹层，内含 <code><label><input type="checkbox" id="dont-ask-again"> 不再提示</label> - 用户点击“确认”时，检查
document.getElementById("dont-ask-again").checked是否为true - 若勾选，存入
localStorage.setItem("skipConfirmDelete", "true")；取消则删掉该 key（removeItem） - 下次触发操作前，先读
localStorage.getItem("skipConfirmDelete") === "true"，为真则直接执行，不弹框 - 永远先做存在性判断：
if (typeof confirm === 'function' && confirm('确定删除？')) { ... } - 但更稳妥的是：彻底弃用
confirm()，统一走自定义模态框路径，避免双路径维护成本 - 如果必须兼容旧代码，可在调用前加一层包装：
const userConfirmed = (window.confirm || (() => true))('...')，但仅作兜底，不用于生产关键路径 - 建议只对低风险、高频、确定性高的操作启用（如“关闭新手引导”、“跳过更新日志”）
- 对删除/解绑类操作，至少要求勾选后额外输入关键词（如“DELETE”）或二次点击“永久删除”按钮
- 在 localStorage 存值时，别只存
"true"，而用带时间戳和操作标识的结构：{"delete-file": {"skip": true, "ts": 1730127384}}，方便后续灰度开关或审计
注意：不要用 sessionStorage，它关页就丢；也不要用 cookie，没这个必要；localStorage 简单直接，且同源下持久有效。
confirm() 被禁用或拦截时的降级处理
某些环境（如 iOS 微信内置浏览器、部分企业微信 WebView）会静默屏蔽 confirm()，返回 undefined 或直接跳过。如果你的“不再提示”逻辑还依赖 confirm() 的返回值做分支，就会出错。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
权限类操作慎用“不再提示”
像删除账户、清空回收站、解除设备绑定这类高危操作，“不再提示”本质是把责任从交互层转移到用户记忆上。一旦用户误勾且遗忘，后果不可逆。
最易被忽略的点：没人检查用户手动清空了 localStorage 后的行为。这时候“不再提示”失效，但界面没任何提示，用户会困惑“怎么又弹了？”——所以首次勾选后，最好在设置页加个显式开关供用户管理。
