class命名应全小写连字符分隔，按功能而非样式命名，避免拼音、中文、驼峰、下划线；推荐BEM结构，JS操作用classList API确保安全。

class名别用中文或拼音

浏览器不报错，但协作和维护时会踩坑。比如 class="用户列表" 在 CSS 里要写成 .用户列表，部分编辑器语法高亮异常，Git diff 显示乱码，Webpack 构建时可能触发编码警告。拼音如 class="yonghuList" 更危险——别人看不懂、搜不到、拼错率高。

实操建议：

立即学习“前端免费学习笔记（深入）”；

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

• 全小写 + 连字符分隔，比如 user-list、header-logo
• 避免下划线（user_list），CSS 里它和伪类 :hover 等容易视觉混淆
• 禁止驼峰（userList），JS 里操作 class 时得用 el.classList.add('userList')，但 HTML 源码里它和语义无关，纯属徒增记忆负担

别让class暴露实现细节

class="red-text" 或 class="float-left" 看似省事，但一旦设计改版，你得全局搜替换，还可能漏掉嵌套组件里的同类名。这不是命名问题，是耦合问题。

实操建议：

立即学习“前端免费学习笔记（深入）”；

• 按功能或内容命名，不是样式效果。比如用 error-message 代替 red-text，用 sidebar-nav 代替 float-left
• 如果真需要控制样式位置，优先用更上层容器的 class 做上下文限定，比如 .article-content .sidebar-nav，而不是给 nav 自己加 float-left
• 工具类（utility class）如 text-center 可以存在，但应严格隔离：单独文件、明确前缀（如 u-text-center）、不参与业务逻辑

BEM 命名不是必须，但结构得有

不用 BEM 也行，但没结构就容易出 button、big-button、btn-primary-active-hover 这种失控命名。BEM 的价值不在双下划线，而在强制你思考「块-元素-修饰符」这三层关系。

实操建议：

立即学习“前端免费学习笔记（深入）”；

• 简单组件用两段式足够：card（块）、card-title（元素）、card--featured（修饰符）
• 避免过度嵌套：不要 card__title__link，而是 card__title-link —— link 是 title 的一部分，不是 title 里的独立元素
• 修饰符名要语义化：card--loading 比 card--gray 更可持续；后者一旦换主题色就失效

JS 操作 class 时注意动态性

很多人写 el.className = 'active'，直接覆盖所有 class，把 user-item、is-collapsed 全干掉了。或者用 el.classList.add('active') 却忘了先 remove 旧状态，导致 class 越堆越多。

实操建议：

立即学习“前端免费学习笔记（深入）”；

• 永远优先用 classList API：add()、remove()、toggle()、contains()
• 切换状态用 replace()：比如 el.classList.replace('idle', 'loading')，比先 remove 再 add 更安全
• 批量操作别链式调用 add(a).add(b).add(c)，IE 不支持；拆成多行或用展开语法：el.classList.add(...['a', 'b', 'c'])

HTML class 名这事，表面是写个字符串，实际是在定义组件边界、预留修改空间、降低团队理解成本。最常被忽略的，是命名一旦定下来，就会在 HTML、CSS、JS、测试代码甚至后端模板里反复出现——改一个，就得同步五处。