HTML Toast 是用 div+CSS+JS 实现的非原生组件，性能取决于 DOM 复用、GPU 加速动画、事件清理等；React 中需用 createPortal 挂载至 body；应支持队列合并、iOS fixed 兼容及生命周期精准管理。

HTML Toast 本质不是原生组件，性能开销取决于实现方式

浏览器本身不提供 Toast 原生 API，所有“HTML Toast”都是用 div + CSS 动画 + JS 控制实现的。它是否“影响轻提示”，关键看你怎么写：DOM 节点是否复用、动画是否触发重排、是否绑定多余事件。

• 每次 showToast() 都 document.createElement('div') → 内存泄漏风险高，频繁调用卡顿明显
• 用 transform 和 opacity 做入场/退场动画 → GPU 加速，基本无卡顿
• 用 top/left 或 height 动画 → 强制同步布局计算，低端机上肉眼可见掉帧
• 未清理 setTimeout 或未解绑 click 事件 → 多次快速弹出后，旧 Toast 仍响应点击或延迟关闭

用 createPortal + CSS-in-JS 管理 Toast 容器最稳妥（React 场景）

在 React 中直接往组件内部挂载 Toast，容易被父组件 shouldComponentUpdate 或 React.memo 阻断更新，导致 Toast 不消失或状态错乱。

• 必须将 Toast 挂载到 document.body 下独立容器，推荐用 ReactDOM.createPortal
• 避免用内联 style 控制显隐，改用 className 切换（如 toast toast--entering），CSS 里定义 @keyframes
• 每个 Toast 实例应有唯一 id，关闭时精确移除对应节点，而不是清空整个容器
• 若用 emotion 或 styled-components，确保 Toast 样式不随父组件重渲染重复注入

Toast.show() 接口设计要支持队列与自动降级

用户连续点击 5 次按钮，不该弹出 5 个堆叠 Toast —— 这既遮挡内容，又消耗资源。真实场景中必须内置节流和队列策略。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 默认开启「同类型 Toast 合并」：比如连续 Toast.info('保存中...')，只保留最后一个，其余取消定时器
• 超时时间应可配，但建议默认 3000ms；手动调用 Toast.hide(id) 时需校验该 id 是否仍在队列中
• 若页面处于后台（document.hidden === true），可跳过渲染，或降级为 console.log（调试阶段很有用）
• 不建议依赖 Promise 返回值做业务流程控制（如 await Toast.success(...)），因为 Toast 是纯 UI 反馈，非业务原子操作

移动端真机测试时，position: fixed 在 iOS Safari 下有兼容陷阱

iOS 15+ 的 Safari 对 fixed 元素在键盘唤起/收起时行为异常：Toast 可能被顶出视口、位置偏移、甚至动画卡死。这不是 Toast 库的问题，是浏览器渲染层 bug。

立即学习“前端免费学习笔记（深入）”；

• 临时方案：检测 navigator.userAgent 包含 iPhone 或 iPad 时，改用 position: absolute + getBoundingClientRect() 动态计算 top 值
• 监听 window.visualViewport（iOS 16.4+ 支持），用其 offsetTop 校正位置
• 禁用 Toast 的 pointer-events: none（如果用了），否则 iOS 上可能无法穿透点击底层元素，造成误触反馈缺失
• 真机必测场景：横屏切换 + 键盘弹出 + Toast 同时出现 —— 这三者叠加最容易暴露定位失效问题

实际项目里，最难调的从来不是怎么让 Toast “弹出来”，而是它在各种边界条件下“安静地消失”。尤其是多 Tab 切换、PWA 离线缓存、WebView 嵌套等环境，Toast 的生命周期管理稍有疏忽，就会变成 UI 层的幽灵节点。