CSS Modules本身不提供响应式能力，响应式逻辑必须写在CSS中，但通过按断点分文件、按功能分模块、结合:export和@import等组织方式，可提升响应式样式的可维护性、复用性与调试效率。
直接说结论：CSS Modules本身不提供响应式能力，响应式逻辑必须写在CSS里，但组织方式决定了你能不能快速维护、复用和调试这些断点规则。
为什么不能只靠localIdentName解决响应式问题
CSS Modules只是把类名做哈希隔离，它不解析媒体查询、不编译@media块、也不感知视口变化。你写的@media (min-width: 768px)会原样输出到最终CSS中——它是否生效，完全取决于浏览器是否匹配条件，跟Modules无关。
常见错误现象是：开发时在桌面端看到样式正常，切到手机预览却失效，一查发现@media规则被包裹在某个组件的局部作用域里，但父容器设置了overflow: hidden或transform，意外触发了层叠上下文，导致媒体查询“视觉上没起作用”。
- 别指望CSS Modules自动帮你做断点提取或主题切换
- 别把响应式逻辑拆到JS里用
useEffect监听window.innerWidth来切类名——这破坏了CSS的声明式本质，也绕过了CSSOM优化 -
localIdentName里加[hash]再长，也不能让@media更易读或更易复用
推荐的响应式样式组织结构：按断点分文件 + 按功能分模块
不要把所有@media塞进Button.module.css里。大型项目要分层管理：
立即学习“前端免费学习笔记（深入）”；
- 根目录下建
styles/breakpoints.module.css，只放基础断点变量（用:export导出JS可读值） - 每个组件的
.module.css文件里，用@import引入断点定义，再写具体规则 - 复杂布局组件（如
Grid、CardList）可额外配Grid.responsive.module.css，专门放多断点网格逻辑
示例：breakpoints.module.css
/* styles/breakpoints.module.css */
:export {
mobile: "(max-width: 767px)";
tablet: "(min-width: 768px) and (max-width: 1023px)";
desktop: "(min-width: 1024px)";
}
<p>@media (max-width: 767px) {
.mobile-only { display: block; }
}</p><p>@media (min-width: 768px) {
.tablet-up { display: flex; }
}组件中使用：
/* components/Card.module.css */
@import "../breakpoints.module.css";
<p>.root {
padding: 1rem;
}</p><p>@media (min-width: 768px) {
.root {
padding: 1.5rem;
}
}动态断点与useMediaQuery配合的边界在哪
CSS Modules管不到运行时，但有些场景确实需要JS介入——比如根据用户偏好（prefers-reduced-motion）或设备方向（orientation: landscape）切样式。这时别硬塞进CSS文件，而是用React Hook封装：
- 用
useMediaQuery（来自@react-hook/media-query或自写）返回布尔值 - 在组件JSX中用该值控制
className，例如className={clsx(styles.root, isLandscape && styles.landscape)} -
styles.landscape仍定义在.module.css里，只是触发条件交由JS判断
关键限制：这类JS驱动的断点，仅适用于低频、语义明确的场景（如深色模式、动效开关）。别用它替代@media做常规响应式布局——性能差、SSR不友好、且无法被CSS压缩工具优化。
容易被忽略的构建细节：Sass/PostCSS与CSS Modules共存时的@media处理
如果你用sass-loader + css-loader?modules，注意@media嵌套行为：
- Sass的嵌套
@media（如.card { @media (min-width: 768px) { padding: 2rem; } }）会被正确展开，不影响Modules作用域 - 但PostCSS插件如
postcss-preset-env的stage: 0可能把@container转成兼容写法，而CSS Modules对@container无特殊处理——它照样哈希类名，但容器查询本身需浏览器支持 - 最坑的是：某些旧版
css-loader（importLoaders > 1时，会把@import进来的@media误判为全局规则，导致哈希失败——务必升级到css-loader@6+并设importLoaders: 2（Sass + PostCSS双loader）
真正难的不是写响应式，而是让断点规则在组件隔离、构建流程、设计系统之间保持可预测的一致性。一旦你开始用@import复用断点、用:export同步JS逻辑、并明确JS和CSS各自负责的断点类型，维护成本就降下来了。
