Notification组件Block名不能叫notification-modal，因其违反BEM语义中性与复用边界清晰原则：混入“modal”实现细节，暗示特定交互，且易与ant-notification等冲突；正确命名应为中性、无渲染假设的notify。
Notification组件的Block名为什么不能叫notification-modal
因为notification-modal违反了BEM的Block命名核心原则：语义中性、复用边界清晰。它混入了“modal”这个实现细节，也暗示了特定交互（遮罩、焦点锁定），而实际通知框可能是inline、toast或banner形态。更糟的是，一旦项目里已有ant-notification或el-notification，这类命名直接引发样式冲突或开发者认知混淆。正确做法是用notify——短、中性、无渲染假设，和dialog一样，是BEM社区已验证的稳定Block名。
notify__icon、notify__message这些Element怎么避免语义越界
Element必须严格对应Block内部的**可复用子结构**，不是HTML标签的直译。常见错误包括：notify__div、notify__span这类基于标签的命名；或把辅助文案写成notify__subtext（语义模糊，不如notify__hint明确其作用）。实操建议：
-
notify__icon只负责图标容器，不控制图标颜色——那属于Modifier职责 -
notify__content作为文字区域总容器，再拆notify__title和notify__body，而非一股脑塞进notify__text - 关闭按钮必须是
notify__close，不能简化为notify__btn——按钮类型不重要，功能意图才关键
notify--success、notify--warning这些Modifier为什么不能叠加成notify--success--dismissible
BEM修饰符必须是「开关式」，每个Modifier表达一个正交状态。把notify--success--dismissible写成双破折号嵌套，等于把两个独立语义耦合成一个新变体，破坏可组合性。真实场景中，你可能需要「成功+可关闭+带进度条」，但没人会写notify--success--dismissible--progress。正确方式是：
- 基础状态用
notify--success、notify--warning等 - 交互能力用独立Modifier：如
notify--closable、notify--autohide - JS层动态添加多个类：
notify notify--success notify--closable notify--autohide - 禁止出现
notify--success-closable这种混合修饰符——它让CSS规则无法被其他Block复用
fixed定位和transform干扰怎么在notify中规避
Toast类通知常用position: fixed配合top/right定位，但若父容器有transform（比如动画容器、缩放布局），fixed会相对该容器定位，而不是视口——这是最常被忽略的渲染陷阱。解决方案不是去掉transform，而是调整定位策略：
立即学习“前端免费学习笔记（深入）”；
- 优先用
position: absolute+ 顶层容器（如#app或.layout）作为定位上下文，并确保该容器position: relative - 若必须
fixed，检查DOM层级是否意外嵌套在transform元素内，用getComputedStyle(el).transform快速验证 - 销毁时务必清理
transitionend监听器，否则连续触发通知会造成内存泄漏——别依赖setTimeout兜底，要用window.getComputedStyle确认过渡结束
__或--时，都得问一句：这个命名是否把归属关系钉死了？有没有把实现细节（modal、flex、icon-font）偷偷塞进语义里？ 
