styles.xxx报undefined是因为CSS Modules默认将带连字符的类名（如.pl-6）转为驼峰式导出键（pl6），导致styles.pl-6或styles["pl-6"]访问失败；实际应使用styles.pl6，且需确保构建配置、类型声明与转换规则一致。
styles.xxx 报 undefined 是因为类名被自动转驼峰了
你在 .module.scss 里写了 .pl-6，但在 JS 中写 styles.pl-6 或 styles["pl-6"]，结果是 undefined——这不是导入失败，也不是路径错了，而是 CSS Modules 默认把带连字符的类名转成了驼峰式导出键。编译后实际生成的是 pl6，不是 pl-6。
你可以立刻验证：在组件里加一行 console.log(styles)，运行后看控制台输出的对象键名，大概率是 pl6、pr12、headerContainer 这类，没有短横线。
- 原始 SCSS：
.pl-6 { padding-left: 6rem; } - 实际导出键：
styles.pl6（✅ 正确） - 错误写法：
styles.pl-6（语法报错）、styles["pl-6"]（运行时可能返回undefined，且 TypeScript 不提示）
不同构建工具对驼峰转换的控制方式不一样
Webpack 5+ 的 css-loader、Vite 的内置 CSS 处理、PostCSS 插件都支持自定义类名转换逻辑，但默认行为不统一，容易踩坑。
- Vite 默认启用
camelCase转换，且不可关闭；若你希望保留pl-6原样导出，得显式配css.modules.localsConvention: 'dashes' - Webpack 中需在
css-loader的modules配置下设localsConvention: 'camelCase'（默认值）或'dashesOnly' - PostCSS Modules 插件用
localsConvention选项，支持'camelCase'、'dashes'、'asIs'等值 -
typescript-plugin-css-modules插件也读取这个配置，决定生成的.d.ts类型里字段名长什么样
TS 报“Property 'xxx' does not exist”其实是类型声明没对上
TypeScript 报错 TS2339 不代表样式没加载，只说明它“以为” styles 对象里没有那个键。根本原因是类型声明文件和实际编译结果不一致。
立即学习“前端免费学习笔记（深入）”；
- 如果你用了
localsConvention: 'dashes'，但类型声明写的是declare module '*.module.scss' { const content: Record<string string>; ... }</string>，那 TS 就不知道styles["pl-6"]是合法的 - 更稳妥的做法是让
typescript-plugin-css-modules自动生成.d.ts文件，并在tsconfig.json中开启"namedExports": true，这样styles.pl6才有类型提示 - 手动声明类型时，别只写
Record<string string></string>，要配合实际转换规则——比如用dashes模式，就得允许字符串索引：[key in 'pl-6' | 'pr-12']: string（但太难维护，不推荐）
开发时最省事的命名习惯：直接写无连字符类名
与其反复调配置、改类型声明、查文档确认转换规则，不如从源头规避问题。SCSS 文件里就别用 .pl-6，改用 .pl6、.pr12、.textLg 这类命名。
- 好处是：所有构建工具默认都能正确导出为
styles.pl6，TypeScript 类型声明能直接推断，IDE 补全可用，HMR 热更新稳定 - 缺点是：牺牲了一点 CSS 工具类的“语义惯性”，但换来的是整个链路的确定性
- 如果团队已大量使用
tailwind-like命名（如px-4），建议统一收口到一个工具类库，而不是每个组件自己定义.px-4—— 避免重复转换和类型失配
真正容易被忽略的点是：类名转换发生在构建阶段，而类型检查发生在编译阶段，两者解耦。你以为改了 SCSS 就行，其实还得同步确认构建配置、插件配置、类型声明三者是否对齐。任一环节错位，styles.xxx 就会静默失效。
