别再让 JavaScript 直接改内联样式，把状态表现交回 CSS

前端开发者在处理样式不生效，或者需要动态切换页面状态时，常常会采用一种“强行覆盖”的思路：CSS 选择器权重不够，就拼接一串冗长的 ID 组合；仍然压不过优先级，就直接加上 !important。比这些更麻烦的做法，是通过 JavaScript 使用 element.style.property 直接修改元素样式。

强行覆盖：用指令式对抗声明式

表面上看，这种方式能迅速解决眼前的问题；但从代码组织上看，它实际上是在用指令式编程对抗 CSS 的声明式机制。

问题的关键，不只是代码风格，而是表现层和逻辑层的边界被混在了一起。比如在 JS 中写下：

element.style.display = 'none'

这个元素的样式最终由谁决定，已经不再只是 CSS 文件。你只是把它交给了某个点击事件的回调函数。放在小型 Demo 里，这种写法可能没什么压力；但项目规模变大之后，维护成本会迅速增加。

当某个元素在特定页面上出现颜色异常时，你可能会先在 .css 或 .scss 文件中不断查找，却始终找不到原因，因为真正改变颜色的值，已经被藏在某段较深的 JS 逻辑判断里了。

级联机制：样式与逻辑的边界混淆

CSS 的级联机制，也就是 Cascading，并不是一个需要被“消灭”的问题。它本身承担着重要的职责，保证样式能够按照既定规则生效。CSS 应该专门负责表现、过渡、布局和渲染，而具体的业务逻辑和应用状态，不应该全部塞进样式规则中。

如果 JS 直接修改内联样式，浏览器会赋予这个值很高的优先级，它会覆盖 CSS 文件中定义的所有规则。这样一来，样式表对页面的控制就会被削弱，样式的来源也变得不再清晰。

以常见的“面板切换”为例，很多开发者会这样写：

// 典型的指令式写法
button.addEventListener('click', () => {
  panel.style.display = panel.style.display === 'none' ? 'block' : 'none';
});

这段代码在运行上当然没有问题，但它把“显示”和“隐藏”这两个具体视觉状态直接固定在了 JS 中。

如果以后需要把简单的 display: none 切换替换成 300ms 的淡入淡出动画，或者希望不同设备上的面板采用不同的显示方式，就必须重新回到 JS 中修改判断逻辑。这样的代码组织方式，显然不利于关注点分离。

最佳实践：JS管状态，CSS管表现

更合适的写法，是让 JS 只负责切换状态标签，至于状态对应的视觉表现，则交给 CSS 决定：

// 推荐的声明式写法：JS 仅负责状态变更
button.addEventListener('click', () => {
  panel.classList.toggle('is-open');
});

/* CSS 负责定义状态对应的表现 */
.panel {
  display: none;
  opacity: 0;
  transition: opacity 0.3s ease;
}

.panel.is-open {
  display: block;
  opacity: 1;
}

这两种方案最终呈现出的视觉效果完全相同，但代码所承担的职责并不一样。

在第二种方案里，JS 只扮演一个“开关”的角色，通过 classList.toggle 告诉浏览器：这个元素当前处于 is-open 状态。至于 is-open 状态下应该显示还是隐藏，应该显示红色还是蓝色，全部由 CSS 文件负责定义。

这种方式的价值在于，后续需要调整 UI 效果时，可以直接在 CSS 文件中修改对应规则，而不必重新翻找 JS 逻辑。由于不再依赖内联样式，你仍然可以借助 CSS 的媒体查询，也就是 Media Queries，在不同屏幕尺寸下为 .is-open 设置不同的表现，也不需要在 JS 中加入复杂的 window.innerWidth 判断。

不要把 JS 当成 CSS 的临时补丁。当你想用 JS 修改样式来换取更快的结果时，可以先尝试定义一个状态类名，把具体表现留在样式表中。这样处理之后，代码的职责会更加清晰，页面状态也更容易预测和维护。