css modules类名变动是正常设计，非bug：构建时基于路径、类名及内容生成哈希，开发环境因salt（如时间戳）变化导致类名跳变，生产环境依赖内容哈希确保稳定；import styles始终映射正确哈希值。
类名变了，但 import styles 仍能正确映射
不是类名“变”了导致样式失效，而是 CSS Modules 的核心机制：它把原始类名（比如 .button）编译成唯一哈希（如 Button_button__abc123），同时生成一个 JS 对象，把 button 这个键映射到那个哈希值。你在 JSX 中写 className={styles.button}，实际插入的是编译后的哈希类名——所以 DOM 上看着“变了”，但逻辑链没断。
关键点在于：styles 对象不是静态字符串字面量，而是构建时动态生成的模块导出，和最终 CSS 文件中的选择器严格对齐。
为什么改个空格或注释，类名就又变了？
哈希计算通常包含 CSS 内容本身（尤其生产环境）。这意味着：
- 哪怕只在
.button { }后加个空格，[hash:base64:5]就可能变成另一个值 - 开发环境还叠加了模块路径、文件名、甚至热更新时间戳等 salt，加剧变动频率
- 这不是 bug，是设计使然：内容一致 → 哈希一致 → 样式可缓存；内容不同 → 哈希不同 → 避免旧样式残留
styles.button 在 SSR 场景下为何有时不匹配？
服务端 Node 环境和浏览器客户端如果用了不同哈希 seed 或不同构建配置，就会算出两个不同的哈希值。比如服务端渲染出 button__xyz，而浏览器 hydrate 时算出 button__abc，React 就会警告“Hydration failed”，甚至丢弃服务端样式。
必须统一哈希逻辑：
- Webpack：用
css-loader的getLocalIdent自定义函数，传入固定seed - Vite：确保
build.rollupOptions和css.modules.generateScopedName一致，且禁用 dev 模式下的 SSR 分歧（如dev.ssr: true可能触发双路径哈希） - Next.js 用户更建议绕开手动配置，直接用
styled-jsx或clsx+ 全局 class 命名约定
调试时类名跳变，怎么稳住 DevTools？
开发阶段频繁刷新导致类名乱跳，确实干扰断点、手写覆盖样式、截图标注。解决思路不是关掉哈希，而是让哈希“可预测”：
- Webpack：在
css-loader的modules.localIdentName加hashPrefix: 'dev'，例如[path][name]__[local]___[hash:base64:5]+hashPrefix: 'dev' - Vite：配
css.modules.generateScopedName: '[name]__[local]___[hash:base64:5]'，并确认没启用ssr相关的 dev 分支逻辑 - 注意：生产环境务必保留内容哈希（如
[hash:base64:8]），否则源码结构容易被反推
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
