在不少后台管理系统和历史项目改造中，开发者会同时使用jQuery处理简易DOM操作和Ajax请求，又引入Dojo Toolkit来使用其成熟的dijit组件库。当这两套框架共存于一个页面时，dijit组件原本正常的样式经常被破坏，比如下拉框高度异常、选项卡文字不居中、按钮背景被改掉。这种问题并不是JavaScript报错，而是CSS层叠规则在起作用。
要理解为什么dijit样式会被覆盖，先得看CSS优先级的基本逻辑。浏览器对每条样式规则都会算一个优先级分值，也叫特异性。分值由选择器类型决定：元素选择器如div权重最低，类选择器如.dijitButton居中，ID选择器如#main最高，再加上行内style和!important的额外权重。当不同规则指向同一元素同一属性，分值高的胜出；分值相同则后加载的覆盖先加载的。
jQuery官方本身并不强制携带大量UI样式，但很多jQuery插件或旧版jquery-ui.css会写诸如.ui-widget、input、button这样的宽泛选择器。Dojo的dijit.css和dijit_rtl.css则用.dijit开头的具体类控制组件。若页面先引dijit样式，后引jquery-ui样式，且jquery-ui用了button元素选择器设了背景，那么dijit的按钮背景就可能被元素级规则冲掉，因为元素选择器虽权重低，但配合后加载顺序仍会造成直观覆盖。
常见冲突场景与定位方法
实际排错时，第一步应用浏览器开发者工具选中变样的dijit节点，查看Computed面板里哪条CSS划了删除线。被划掉的正是败给更高优先级规则的原dijit声明。此时能看到覆盖来源是jquery相关样式表里的某行，还是自己写的公共reset.css。
有一类典型场景是全局reset。很多jQuery项目喜欢用含input,select,button { font-family: xxx; box-sizing: border-box }的reset片段，而dijit对box-sizing非常敏感，一旦被改成border-box，其用背景图拼出的控件就会错位。这种覆盖甚至不涉及类名冲突，纯粹是元素选择器太广。
解决CSS优先级冲突的实用方案
最直接的方法是调整样式表加载顺序。把dijit的css放在jQuery插件css之后引入，让dijit的具体类规则靠后，同等权重下胜出。但这要求你能控制引入位置，且jquery-ui没有用!important。若不能改顺序，可提升dijit选择器具体度，例如写.dijit.dijitButton而非单写.dijitButton，或用父级容器加独有类名前缀。
更稳妥的是命名空间隔离。给Dojo容器包一层
| 方案 | 操作难度 | 适用情况 | 副作用 |
|---|---|---|---|
| 调整引入顺序 | 低 | 可自由排布link标签 | 后续加插件易再冲突 |
| 提升选择器具体度 | 中 | 少量组件异常 | 需写额外css维护 |
| 命名空间隔离 | 中高 | 长期共存架构 | 初始改造稍繁 |
| 使用!important | 低 | 紧急修复 | 破坏可维护性 |
不推荐滥用!important，它虽能立刻压住jquery样式，但会让日后主题切换和响应式调整变得棘手。经验上，用命名空间加具体度提升组合，基本能彻底隔开两套框架的样式世界。
通过构建工具避免未来冲突
若项目用webpack等打包，可为dojo样式配置css-loader的modules选项，把dijit类名局部哈希化，从根源消灭全局类名碰撞。jQuery插件样式则可单独抽离，在入口处明确先后。这样即便同页，也不会出现裸类名互踩。
另外，团队应约定第三方框架样式不写元素级全局规则。例如禁止在公共css里写button { }，改为.jq-btn { }。只要 everyone 遵守，jQuery与Dojo Toolkit同页时dijit组件样式被覆盖的麻烦就能大幅减少，页面视觉也稳定得多。
jQueryDojo_Toolkitdijit样式覆盖修改时间：2026-08-10 12:51:38