Next.js 15 中 BEM 类名失效是因为 Server Components 下 CSS Modules 自动哈希类名，导致手动拼接的 block__element--modifier 字符串无法匹配；必须通过 styles 对象动态获取类名并用 clsx 组合，避免硬编码。
为什么 className 里写 BEM 在 Next.js 15 里容易失效
因为 Next.js 15 默认启用 app 目录 + Server Components，所有 CSS 文件（包括 .module.css）在服务端渲染时会被自动作用域隔离——类名被哈希化，block__element--modifier 这种手写字符串会直接丢失对应样式。你写的 className="header__logo--large"，实际生成的 DOM 类名可能是 header__logo--large_xxx，但样式里绑定的是哈希后的类名，根本对不上。
用 clsx + cssModule 动态拼接才安全
必须放弃硬编码类名字符串，改用模块导入 + 工具函数组合。核心是让 BEM 结构由 CSS 模块对象驱动，而不是人肉拼写。
-
import styles from './Header.module.css'—— 确保所有类名都来自这个对象，哪怕它看起来像styles['header__logo'] - 用
clsx合并多个 BEM 片段：clsx(styles.header, styles['header__logo'], isLarge && styles['header__logo--large']) - 如果要用嵌套 BEM（如
header__nav-item），必须在.module.css中明确定义该类，不能靠字符串拼接：header__nav-item必须是独立 key，不能写成styles.header__nav + '-item'
app 目录下 Client Component 的特殊处理
如果你在 'use client' 组件里用 useState 控制 BEM modifier，要注意：服务端生成的初始类名和客户端 hydration 后的类名必须一致。否则会触发 React 警告甚至样式错乱。
- 所有 modifier 判断逻辑（如
isHovered、isActive）必须在服务端可静态求值，或延迟到useEffect后再应用——但后者会导致 FOUC - 推荐方案：用
useMemo包裹clsx调用，并确保依赖数组包含所有影响类名的变量 - 避免在
className中混用模块类名和全局类名（比如同时写{styles.header} header--fixed），后者无法被 CSS Modules 作用域保护，可能污染其他组件
想复用 BEM 工具函数？别封装太重
有人会写 bem('header')('logo', { large: true }) 这类工具，但在 Next.js 15 的 SSR 场景下，这类函数若内部依赖 window 或未处理服务端/客户端差异，极易出错。
立即学习“前端免费学习笔记（深入）”；
- 最简方案：每个组件只维护自己的
cn辅助函数，基于当前styles对象闭包，例如：const cn = (block: string, element?: string, modifier?: string) => { const base = styles[block]; const el = element ? styles[`${block}__${element}`] : ''; const mod = modifier ? styles[`${block}__${element || block}--${modifier}`] : ''; return [base, el, mod].filter(Boolean).join(' '); }; - 不要跨组件共享通用 BEM 工厂函数——不同模块的
styles对象不互通，强行抽象反而增加 runtime 错误风险 - 如果项目中大量使用相同 block，可提取为常量（如
const HEADER_BLOCK = 'header';），但不要试图抽象出“BEM 命名空间管理器”
