应使用 element.classList.add()/remove()/toggle() 替代 className 直接赋值，避免覆盖原有类名；状态类统一加在外层容器，服务端仅输出基础类名，客户端注入动态状态类。
Element.className 直接赋值会覆盖全部类名
很多人以为 element.className = "active" 是给元素“添加”一个类，其实它会清空原有所有类，只保留 "active"。这对编辑器状态切换很危险——比如你原本有 "editor toolbar-focused resizable"，一赋值就只剩 "active"，工具栏、缩放等样式全丢。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
element.classList.add()/.remove()/.toggle()替代直接操作className，这是现代浏览器标准做法 - 如果必须用
className（比如兼容 IE9），得先读取再拼接：element.className = element.className.replace(/\bactive\b/g, '') + ' active' - 编辑器常见状态如
"loading"、"disabled"、"readonly"，应独立管理，避免和布局类（如"editor-fullscreen"）耦合
classlist.toggle() 适合开关类，但要注意布尔逻辑陷阱
element.classList.toggle("focused") 看似方便，但编辑器焦点状态往往不单靠 DOM 是否聚焦决定——比如富文本编辑器里，光标在 iframe 内时 document.activeElement 可能不是编辑器容器本身。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要仅依赖
focus/blur事件调用toggle()，需结合contentEditable状态或iframe.contentDocument.activeElement判断 - 对多状态互斥场景（如
"editing"/"preview"/"source"），用replace()更安全：el.classList.replace("preview", "editing") - IE10+ 才支持
replace()，若需兼容旧版，先remove()再add()
动态类名需配合 CSS 层级与属性选择器防冲突
编辑器组件常嵌套多层，比如 <div class="editor"><textarea></textarea></div>。如果只写 .editor.active textarea，状态类加在父容器上没问题；但若加在 textarea 自身上，而 CSS 里又用了 .editor textarea:disabled，优先级可能出问题。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 状态类统一加在最外层容器（如
editor元素），避免分散到子节点，减少 CSS 权重博弈 - 用属性选择器强化意图，例如
[data-state="loading"] .editor-toolbar比单纯.loading .editor-toolbar更不易被第三方样式覆盖 - 避免用
!important解决类名冲突——它会让后续状态叠加（如同时有"error"和"success"）变得不可预测
服务端渲染或 SSR 场景下 className 初始化易错
Next.js、Nuxt 等框架中，组件首次渲染由服务端完成，此时 JavaScript 未执行，className 是静态的。若初始状态（如 "dirty"）需根据 props 计算，直接写死 HTML 类名会导致首屏与客户端不一致（hydration mismatch）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 服务端只输出基础类名（如
"editor"），状态类一律由客户端 JS 注入，用useEffect或componentDidMount触发 - 若必须服务端输出状态类，确保服务端与客户端使用完全相同的判断逻辑，例如都基于
props.isDisabled而非document.hasFocus() - React 中可借助
suppressHydrationWarning临时绕过警告，但只是掩耳盗铃，根源仍是类名生成逻辑不一致
contentEditable 元素和 iframe 编辑器，DOM 焦点与业务焦点常常错位，这时候硬套 classList.toggle() 就会漏掉真实状态。 
