首先，我明白这种配置看起来都对但结果不符合预期的情况有多头疼，结合你的代码和配置，给你几个针对性的排查方向：

• 确认css-loader版本与配置的兼容性
  如果你的css-loader是v4及以上版本，modules: true的写法虽然兼容，但更推荐明确设置模块模式来避免解析歧义：

  options: {
    modules: {
      mode: 'local',
      localIdentName: '[name]__[local]__[hash:base64:5]'
    },
    // 其他原有配置...
  }
  

  旧版本的css-loader对modules: true的解析逻辑可能存在差异，你可以先尝试这种写法，或者查看css-loader的版本日志，确认是否有配置项变更影响了模块化解析。

• 检查webpack规则的优先级与完整性
  确保你的.css处理规则是唯一的，没有其他更早的test: /\.css$/规则覆盖了当前配置——比如如果有处理全局CSS的规则排在前面，会导致你的模块化CSS规则不生效。另外，检查配置片段是否完整：你设置了importLoaders: 1，意味着css-loader之前会有1个loader处理@import的CSS（比如postcss-loader），如果没配置这个loader，也可能导致解析异常；同时确认生产环境中ExtractTextPlugin.extract的参数是否闭合完整。

• 验证CSS文件的有效性与路径
  虽然你的CSS代码看起来没问题，但可以做几个小验证：

  • 在Header.css里加一个显眼的样式（比如color: red !important），然后直接用全局类名<div className="Header">测试，看样式是否生效——如果生效，说明CSS文件路径没问题，问题出在模块化解析；如果不生效，说明CSS文件没被正确加载，要检查路径或webpack规则。
  • 确认CSS文件里没有语法错误（比如遗漏分号、括号不匹配），语法错误可能导致css-loader解析失败，返回空对象。

• 排查ExtractTextPlugin的兼容性问题
  ExtractTextPlugin已经被官方弃用，推荐使用mini-css-extract-plugin替代。旧版本的ExtractTextPlugin和css-loader的modules模式配合时，可能存在解析bug。你可以尝试临时替换成mini-css-extract-plugin，或者在生产环境暂时用style-loader+css-loader的组合（和开发环境一致），看classes对象是否正常。

• 检查webpack的mode与tree-shaking影响
  生产环境下webpack默认开启tree-shaking，如果你的代码中classes.Header的使用方式被webpack误判为未使用，可能会被摇掉。你可以尝试在生产配置中临时关闭tree-shaking：

  optimization: {
    usedExports: false
  }
  

  或者在代码中强制保留classes的引用（比如你已经加了console.log(classes)），测试是否能拿到正确的classes对象。

• 简化配置逐步排查
  先把配置简化到最基础的状态：去掉minimize、sourceMap、importLoaders这些选项，只保留style-loader+css-loader+modules: true，看是否能正常导入classes。如果可以，再逐个加回选项，找到导致问题的配置项。

内容的提问来源于stack exchange，提问作者208_man