按钮响应慢主因是HTML结构或事件绑定不当；应改用原生button、压平DOM深度、选对事件委托容器，并确保触控区域≥48×48px。

按钮响应慢，八成不是JS卡，而是HTML结构或事件绑定方式拖了后腿。直接换用原生 、压平DOM深度、选对事件委托容器，就能立竿见影。

为什么比

快又稳

原生

自带焦点管理、键盘支持（Enter/Space）、:active 状态触发通道，浏览器对它的事件路径做了专门优化；而

是纯 JS 模拟，既不进 Tab 键焦点流，也不被屏幕阅读器识别，Safari 还可能跳过 :active 样式渲染。

• 必须用 替代所有带点击行为的
  ，哪怕只调用 onclick="doSomething()"
• 禁用 role="button"：它不自动获得焦点、不响应键盘、在部分安卓 WebView 中完全失效
• 若需重置样式，用 button { all: unset; }，别靠 JS 绑定 click 事件去“补功能”

DOM嵌套超6层会明显拖慢touchstart

touchstart 从手指落到屏幕，到触发 handler，中间每多一层 DOM，就多一次冒泡检查。实测低端安卓机上 6 层嵌套平均延迟 42ms，而 3 层结构稳定在 8–12ms——已逼近人对“即时反馈”的容忍阈值（100ms）。

• 用 Chrome DevTools → Elements 面板右键任意元素 → Show DOM properties 查看 depth 值，超过 6 就该重构
• 砍掉只为加 class 或 JS 选择器而套的
  ，改用 display: contents（Safari 15.4+ 支持）抹除渲染但保留语义流
• 动态插入菜单项时，用 DocumentFragment 批量 append，别循环 appendChild——每次调用都可能触发 layout

事件委托别挂document，选最近静态父容器

把监听器挂在 document 或 window 上，冒泡要从最内层逐层查到根节点，路径太长；换成离按钮最近的、页面加载时就存在的静态容器（如 id="search-results" 的

），冒泡提前终止，性能提升肉眼可见。

• 父容器必须在页面加载时就存在，不能是后续用 innerHTML 动态插入的
• 避免用 class 名模糊匹配（如 .item），优先用 data-action 属性做精确判断：e.target.matches('button[data-action="remove"]')
• 若父容器本身可能被 replaceWith() 替换，监听器就失效了，得重新绑定；但用 innerHTML 重写内容不影响委托

触摸目标尺寸不达标，点不中不是手抖是HTML没写对

CSS 像素 ≠ 实际可触区域。W3C 要求最小触控区域为 48×48 CSS 像素，但只设 width: 48px; height: 48px 不够——文字按钮受 font-size 和 line-height 影响，图标按钮需包裹或伪元素撑开尺寸。



DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

• 用 min-width: 48px; min-height: 48px 强制保底，比固定宽高更可靠
• 包裹 是最稳的热区放大方案：整个 盒模型（含 padding、伪元素）都是可点区域，不依赖 id、不走事件冒泡
• 必须是 的**直接子节点**，不能有换行或空格：同意，而非带空格或换行的写法

真正卡顿的地方，往往藏在 label 里没闭合的标签、button 外多套的 div、事件监听器挂在 document 上还配了个模糊 class 选择器——这些细节不修，再好的防抖和虚拟列表也救不了点击体验。