真正导致html膨胀的是modifier堆叠失控、组件边界模糊、状态逻辑错位；应限制modifier数量≤5个、拆分高危命名、提升共享状态、优化css modules类名生成策略。
别缩写类名，也别指望 SCSS 嵌套或命名空间“压”出短名——真正导致 HTML 膨胀的，是 Modifier 堆叠失控、组件边界模糊、状态逻辑错位。压缩类名只会让调试和协作更痛苦。
Modifier 堆叠为什么让 HTML 体积飙升
像 user-card__avatar--size-lg--theme-dark--is-loading 这种类名，在列表渲染 20 次时，光这个字符串就增加约 1.2KB（未 gzip）。它不是语义问题，而是把配置逻辑全塞进了 HTML。
- Modifier 必须离散、互斥、可枚举；禁止形容词堆叠（如
--very-big-and-centered） - 一个 Block 的 Modifier 总数建议 ≤ 5 个（
--primary、--disabled、--sm、--lg、--outline） -
--size-lg和--theme-dark若只控制间距、颜色等可变量，应交给 CSS 自定义属性，而非硬编码进 class - 布尔型状态（如
--is-loading）可以保留，但必须和 Block 类名共存：user-card__avatar user-card__avatar--is-loading，不能单独出现
组件边界不清比类名长更致命
当出现 profile-page__user-card__avatar，问题不在命名长度，而在把页面容器（profile-page）和功能组件（user-card）混为一谈。BEM 的 Block 应该是可复用、有独立状态的单元，不是 DOM 路径快照。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 判断是否该拆 Block：这个子结构能否被抽到其他页面复用？是否有自己的 JS 行为（如
handleClick）或 CSS 状态（如is-expanded）？ -
status-badge不该是user-card__status，而应是独立 Block；card__content是高危命名，优先拆成card__body、card__meta、card__actions - 多元素共用同一状态（如“加载中”），应提升到父级：
dashboard--is-loading，再用选择器批量控制：.dashboard--is-loading .dashboard__header
CSS Modules 类名臃肿该配什么 generateScopedName
默认生成的 _button__clickable___zXy9F_12 类名既难读又拖慢构建。这不是靠删空格能解决的，得从 generateScopedName 或 localIdentName 入手控制输出结构。
- 推荐格式：
[name]_[local]_[hash:base64:5]——[name]保模块上下文，[local]保语义，[hash:base64:5]足够防冲突且比默认:8缩短近 40% - 避免用
[path]或嵌套多层[folder]，路径越深类名越不可控，构建缓存失效越频繁 - JS 层必须配合
localsConvention: "camelCase"，否则styles.btnPrimary会找不到对应 key - 禁用字符串拼接类名：
className={`${styles.btn} ${styles['btn--' + type]}`会让所有变体打进 bundle；改用提前枚举或 CSS 变量驱动
最常被忽略的一点：HTML 类名长度问题，90% 出现在「页面容器」和「功能组件」职责混淆时。与其花时间缩写 user-card__avatar，不如先确认 user-card 是否真该是一个 Block，以及 avatar 是否真的不该是独立的 avatar 组件。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
