Next.js中CSS Modules与BEM的协作边界在于：BEM语义必须由开发者在.module.css中静态书写（如.button__icon、.button--primary），CSS Modules仅负责将其哈希化隔离，而非替代命名约束；文件名即块名，禁止跨块写类、禁用后代选择器、修饰符须可静态预测并安全引用，确保SSR一致性与跨组件边界清晰。
Next.js中CSS Modules与BEM的协作边界在哪？
不是“用不用BEM”，而是“BEM语义如何映射到CSS Modules的哈希类名”。Next.js默认启用CSS Modules，Button.module.css里写.button会被编译成Button_button__abc123，此时BEM结构已由文件名+类名共同承载。真正要做的，是让开发者写的类名本身仍符合BEM逻辑，而不是放弃命名约束去依赖哈希。
常见错误现象：在Button.module.css里写.primary或.large，结果组件复用时无法区分是Button的变体，还是全局通用样式；更糟的是，cn('button', 'primary')这种拼接直接绕过CSS Modules作用域，导致样式泄漏。
- 块名必须与文件名一致：
Card.module.css只允许出现.card、.card__header、.card--featured - 禁止在CSS Modules中使用后代选择器：
.card .title→ 必须写成.card__title，否则破坏模块隔离 - 修饰符类名必须可被JS安全引用：用
styles['card--featured']而非手拼字符串，避免大小写/连字符错误
服务端渲染时BEM类名必须静态可预测
SSR场景下，服务端生成的HTML类名必须和客户端hydrate时完全一致，否则触发Hydration failed because the initial UI does not match what was rendered on the server。这意味着所有BEM类名不能依赖运行时计算（如useId()、随机字符串、环境变量拼接），也不能靠JS动态推导。
容易踩的坑：用clsx拼接base + '--' + variant看似简洁，但若variant来自getServerSideProps以外的异步数据（比如客户端fetch），服务端就无法预知完整类名。
- 所有BEM类名必须在组件顶层静态声明，例如
const BLOCK = 'product-card' - 修饰符枚举值应硬编码或从
props传入字符串字面量，避免条件分支嵌套过深 - 禁用基于DOM尺寸、滚动位置等客户端状态生成修饰符——这类状态应交由
data-属性或独立状态类（如is-scrolled）处理
如何让BEM在App Router中保持跨组件一致性？
App Router的布局嵌套（layout.tsx → page.tsx → components/）天然鼓励样式穿透，但BEM要求每个块有明确边界。关键不是“把所有样式塞进一个layout.css”，而是让每个components/子目录成为独立BEM块的物理载体。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
典型反模式：app/(marketing)/layout.tsx里定义.hero，然后在app/(marketing)/page.tsx里写——这违反BEM的块归属原则，hero__title实际属于hero块，但hero本身未被封装为独立组件。
- 每个功能区块必须有对应组件文件，如
components/Hero/Hero.tsx+components/Hero/Hero.module.css - 布局文件（
layout.tsx）只负责容器结构和className透传，不直接写BEM类名 - 跨组件复用元素（如
icon）应升格为独立Block：Icon组件，而非button__icon——后者暗示它从属于button，实际却可能被menu、card等多处调用
为什么PostCSS BEM插件在Next.js中基本用不上？
Next.js内置的CSS Modules已解决作用域问题，而PostCSS BEM插件（如postcss-bem）的核心价值是自动补全&__content为.block__content。但在Next.js中，你本就不该写&__content——Sass嵌套会破坏CSS Modules的哈希稳定性，且Next.js官方不推荐在App Router中混用Sass。
真正需要的是静态校验，不是自动补全。工具链错位会导致更隐蔽的问题：比如插件把.button:hover转成.button__hover，而--hover根本不是合法修饰符（伪类状态不应进入BEM命名）。
- 用
stylelint-selector-bem-pattern替代PostCSS插件，规则设为{"componentName": "[a-z][a-zA-Z0-9]+", "styleType": "bem"} - 在
next.config.js中配置eslintConfig，确保npm run dev时实时报错 - CI流程中跑
npx stylelint 'src/**/*.{css,scss,ts}'，阻断.card-title或.menu_item这类破规提交
BEM在Next.js里最易被忽略的点，是误把CSS Modules的哈希当作“已经隔离了，命名随便写”。其实哈希只管作用域，不管语义——Button_button__xyz和Button_primary__abc之间毫无关系，除非你强制用.button--primary这种结构，才能让团队一眼看出它们属于同一变体体系。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
