Toast 样式定制必须修改 .toast 规则，因其为 flex 容器并控制定位、圆角、阴影等；.toast-body 仅负责内边距和文字样式，且受父级 background 和 overflow: hidden 限制。
Toast 样式定制必须从 .toast 规则入手，不能只改 .toast-body
Bootstrap 5 的 Toast 是 flex 容器，所有定位、间距、圆角、阴影都由 .toast 自身控制；.toast-body 只管内边距和文字样式。直接覆盖 .toast-body 的 background 或 border-radius 不生效，因为父级 .toast 的 background 和 overflow: hidden 会裁掉子元素溢出部分。
常见错误现象：给 .toast-body 加了 border-radius: 12px，但视觉上还是直角——其实是 .toast 默认的 border-radius: 0.25rem 被你忽略了，而它的背景色盖住了子元素的圆角。
- 想改整体圆角：覆盖
.toast的border-radius，不是.toast-body - 想改阴影强度：重写
.toast的box-shadow，默认是0 0.5rem 1rem rgba(0,0,0,.15) - 想让 header 和 body 颜色分离：用
.toast-header+.toast-body分别设background，但要确保.toast本身background: transparent，否则会遮挡 - 移动端适配注意：
.toast默认有min-width: 350px，小屏下会横向溢出，建议用@media (max-width: 576px)改成width: calc(100% - 2rem)
data-bs-autohide=false 后手动 hide() 容易漏掉 hidden.bs.toast 事件监听
禁用自动关闭后，用户点 × 关闭或调用 toast.hide()，组件只是隐藏（opacity: 0; visibility: hidden），DOM 还在。如果频繁弹 Toast 又不清理，页面里会堆满不可见节点，影响性能。
正确做法是监听 hidden.bs.toast 事件，在隐藏完成后再移除元素：
const toastEl = document.getElementById('my-toast');
const toast = bootstrap.Toast.getOrCreateInstance(toastEl);
<p>toastEl.addEventListener('hidden.bs.toast', () => {
toastEl.remove(); // DOM 真实移除
});</p><p>toast.show();
- 不要用
toast.dispose()替代remove()：它只销毁实例，不删 DOM - 如果 Toast 是动态生成的（如 API 返回后
insertAdjacentHTML插入），必须在插入后立即绑定事件，不能提前写死 - 多个 Toast 共用同一事件监听器？不行。每个
toastEl都得单独绑，否则remove()会误删其他 toast
右下角堆叠 Toast 时 z-index 冲突的真实来源不是 toast 本身
单个 .toast 默认 z-index: 1090，但多个堆叠时，真正决定谁在上层的是它们在 DOM 中的顺序（后插入的在上），不是 z-index 值。如果你把所有 toast 都塞进同一个 .toast-container，又没控制插入顺序，就会出现点击失灵、遮挡内容的问题。
更关键的是：容器自身必须设 z-index，且要高于 navbar（1000）、modal-backdrop（1050）等常见组件：
- 容器标签必须是
<div class="toast-container position-fixed bottom-0 end-0 p-3">，不能是<section>或没 class 的<div> - 务必加内联
style="z-index: 1500000"，Bootstrap 的 CSS 文件里没有预设这个值，靠 class 拉不起来 - 避免在容器上写
overflow: hidden：会把超出容器的 toast 裁掉，尤其动画中位移阶段 - 移动端键盘弹起时，
bottom-0会贴到键盘顶边，建议加 JS 监听resize动态切到top-0位置
Toast 的 aria-live="assertive" 不能删，但可配合 polite 实现多级提示优先级
删掉 aria-live="assertive" 后，屏幕阅读器可能完全跳过 toast，或者延迟播报。这不是 bug，是 WAI-ARIA 规范要求：紧急通知（如表单提交失败）必须用 assertive，普通提示（如“已复制到剪贴板”）可用 polite。
实际项目中，你可以按语义区分两类 toast：
- 错误/警告类：保留
role="alert"+aria-live="assertive"，强制打断当前语音流 - 操作反馈类：改用
role="status"+aria-live="polite"，等用户空闲时再读 - 两者共存时，浏览器会按插入顺序+优先级播报，
assertive总是插队 - 别给同一个 toast 同时写两个
aria-live值——行为未定义，实测 Chrome 会取第一个
定制越深，越容易动到无障碍逻辑。改样式可以大胆试，改 role 或 aria-live 前，务必用 NVDA 或 VoiceOver 实测两遍。
