BEM本身不处理环境差异，但修饰符是绑定环境变量最自然的钩子；关键在于每个修饰符只表达一个可枚举、可测试、可组合的状态语义，如--layout-stack、--theme-dark、--compat-ie11，禁用技术值与混合命名，通过CSS自定义属性实现运行时适配。
直接说结论：BEM本身不处理环境差异，但修饰符（--modifier）是绑定环境变量最自然的钩子；关键不是“加个--mobile”，而是让每个修饰符只表达一个可枚举、可测试、可组合的状态语义。
修饰符必须对应明确的环境维度，不能混业务逻辑
常见错误是把环境判断塞进类名里，比如.card--mobile-login或.button--ie11-dark。这类命名既不可复用，也无法被自动化工具识别，更没法做单元测试。
- 正确做法：拆成正交修饰符——
.card--layout-stack（布局意图）、.card--theme-dark（主题意图）、.card--compat-ie11（兼容意图） - 每个修饰符只负责一个维度，且值必须是预定义集合，如
--density-compact、--scale-125，禁用--scale-1.25这种技术值 - 环境检测逻辑收口在 JS 层，比如用
matchMedia监听(prefers-reduced-motion)后，统一加body--reduced-motion，再让子组件响应这个根级修饰符
多环境样式不能靠覆盖写，得靠自定义属性注入
纯类名切换只能做静态分支，真实环境适配需要运行时变量——比如触控设备要加大点击区域，暗色模式要改色值，IE11 要降级 flex-gap。这些都不能靠.button--touch { padding: 12px; }硬写。
- 修饰符只设 CSS 自定义属性：
.button--touch { --btn-padding-y: 12px; --btn-padding-x: 24px; } - 基础规则用
var(--btn-padding-y)消费：.button__label { padding: var(--btn-padding-y) var(--btn-padding-x); } - IE11 兜底必须显式声明：
.button--compat-ie11 { --btn-padding-y: 10px; }，不能依赖@supports——它在 IE 中无效
构建时环境变量和运行时修饰符要对齐
Webpack 或 Vite 的 process.env.NODE_ENV 是构建时概念，而 BEM 修饰符是运行时 DOM 状态。两者错位会导致 SSR 渲染和客户端 hydration 不一致，尤其在微前端或服务端直出场景下。
立即学习“前端免费学习笔记（深入）”；
- SSR 模板中，用服务端环境变量生成初始修饰符，如 Java 模板输出
<div class="header header--env-prod"> <li>客户端 JS 不要重写整个 classList，而是用<code>el.classList.toggle('header--env-prod', isProd)做增量同步 - 禁止在构建时动态拼接 BEM 字符串，比如
clsx(`${BLOCK}--env-${NODE_ENV}`)——这会让开发/测试/生产三套 CSS 实际使用同一份类名，失去隔离意义 - 正确方案：用 wrapper block 包一层，如
<div class="form-field--date"><datepicker></datepicker></div>，所有环境适配逻辑落在form-field上 - Wrapper 的修饰符可透传给内部组件，例如
form-field--theme-dark触发 JS 向 DatePicker 注入theme="dark"prop - CSS Modules 或 Shadow DOM 可作为兜底，但 BEM wrapper 是唯一跨技术栈（React/Vue/原生 HTML）都有效的契约
第三方库和自定义 BEM 必须划清 Block 边界
Ant Design 的.ant-btn或 Tailwind 的bg-blue-500无法参与你的修饰符体系。强行混合会破坏状态一致性，比如.ant-btn--theme-dark根本不会生效。
最容易被忽略的一点：修饰符的组合爆炸必须靠设计系统收敛，而不是靠开发者手写。一个button块最多支持--size、--variant、--state、--env四个维度，每维不超过 3–5 个取值——超出这个范围，就该拆新 Block，而不是堆修饰符。
