MediaWiki从1.25版本开始逐步把界面体系从jQuery UI迁移到OOUI，但这个迁移过程持续了很多年，大量第三方扩展仍然依赖jQuery UI，于是现实中经常出现一个页面同时加载两套组件库的情况。最典型的症状是：datePicker点不开、dialog弹出来位置跑到页面左上角、按钮绑定的click事件莫名其妙失效、jQuery UI的样式被OOUI的CSS覆盖得面目全非。这些问题的根源可以归纳为三类：事件机制冲突、DOM结构被改写、CSS选择器命中范围过宽。下面逐一分析并给出对应的解决方案。
一、先弄清楚两套库的事件机制差异
jQuery UI和OOUI都构建在jQuery之上，但事件处理思路完全不同。jQuery UI倾向于直接在原始DOM元素上绑定事件，并通过_on、_bind等内部方法管理；OOUI则引入了ViewModel式的封装，组件本身是一个JavaScript对象，DOM元素只是它的视图层投影，事件通过connect()方法显式声明。
冲突往往发生在双方都对同一块DOM区域做事件代理的时候。比如你在一个jQuery UI dialog里嵌入了一个OOUI的DropdownWidget，dialog会拦截mousedown事件来做拖拽和焦点管理，而DropdownWidget也需要mousedown来切换展开状态。如果dialog的modal选项为true，它还会挂一个全局的overlay层，直接吞掉所有冒泡到document的事件，OOUI组件就完全收不到交互了。
排查这类问题的第一步是确认事件到底被谁吃掉了。可以在浏览器控制台用getEventListeners（Chrome DevTools命令行API）检查目标元素上挂了哪些监听器，再配合事件断点单步跟踪。一个实用技巧是给可疑元素临时加一个捕获阶段的监听器：
// 在捕获阶段截获事件，判断事件流是否被中途拦截
document.addEventListener( 'mousedown', function ( e ) {
console.log( 'mousedown 到达 document，目标：', e.target );
}, true ); // true 表示捕获阶段如果这个捕获阶段的监听器都没有输出，说明事件在更底层就被stopPropagation了；如果有输出但OOUI组件没反应，问题多半出在OOUI的事件绑定时机或元素被替换上。
事件命名空间隔离与冲突修复
jQuery的事件命名空间机制是解决冲突的核心工具。jQuery UI内部的组件事件都挂在组件自身的命名空间下，比如datepicker的事件在.datepicker命名空间，但你自己的代码如果裸写$( '#foo' ).on( 'click', handler )，就可能与组件内部的清理逻辑打架。规范的做法是给所有自定义事件都加上命名空间：
// 给自定义事件加命名空间，避免与组件内部事件互相干扰
$( '#my-widget' ).on( 'click.myscript', function () {
// 处理逻辑
} );
// 销毁组件时只解绑自己的事件，不碰组件内部的
$( '#my-widget' ).off( '.myscript' );对于dialog吞事件的问题，有几个方向可以处理。首先是避免使用modal: true，改用非模态弹窗，让事件可以正常冒泡。如果必须模态，可以把OOUI组件的DOM节点手动append到dialog的ui-dialog容器内部而不是overlay之外，并且确认OOUI组件初始化发生在dialog的open回调之后：
// 正确的初始化顺序：先创建容器，再挂dialog，最后初始化OOUI组件
var $container = $( '<div>' ).appendTo( 'body' );
$container.dialog( {
open: function () {
// dialog 打开后再创建OOUI组件，确保元素已在DOM中且可见
var dropdown = new OO.ui.DropdownWidget( {
$overlay: $container.find( '.ui-dialog-content' ), // 指定overlay挂载点
menu: { items: [ new OO.ui.MenuOptionWidget( { data: 'a', label: '选项A' } ) ] }
} );
$container.find( '.ui-dialog-content' ).append( dropdown.$element );
}
} );这里的$overlay参数很关键。OOUI的下拉菜单、日期选择等浮层组件默认把浮层挂到body下，如果dialog是模态的，浮层就会被overlay挡住。把$overlay指向dialog内容区，浮层就会渲染在dialog内部，层级问题一并解决。
还有一种常见情况是重复初始化。MediaWiki的mw.hook机制下，wikipage.content钩子可能在预览、SectionGateway局部刷新时触发多次，如果你在钩子里既初始化了jQuery UI组件又初始化了OOUI组件，第二次触发时旧实例没有销毁，事件就会叠加。解决办法是在初始化前先检查或销毁：
mw.hook( 'wikipage.content' ).add( function ( $content ) {
$content.find( '.my-datepicker' ).each( function () {
var $el = $( this );
if ( !$el.data( 'datepicker' ) ) { // 防止重复初始化
$el.datepicker( { dateFormat: 'yy-mm-dd' } );
}
} );
} );样式隔离：让两套CSS互不侵犯
样式冲突比事件冲突更直观也更恼火。jQuery UI的CSS基于ThemeRoller生成的ui-前缀类名，OOUI使用oo-ui-前缀，理论上类名不冲突，但实际有两类交叉污染。第一类是双方都使用了较宽泛的元素选择器或位置选择器，例如某些主题包会对.ui-dialog button这样的复合选择器设置样式，而dialog里恰好嵌了OOUI的ButtonWidget，其真实DOM就是button元素，于是被误伤。
第二类是CSS加载顺序问题。MediaWiki的资源加载器按依赖关系注入样式，扩展的CSS默认在核心之后加载，如果你的扩展样式依赖jQuery UI主题，而另一个扩展后加载了OOUI的 oojs-ui-core 样式，.oo-ui-buttonElement-button上的一些重置规则（比如background: transparent）就会覆盖jQuery UI的按钮渐变背景。
解决样式隔离最可靠的手段是作用域限定。把jQuery UI组件包在一个自定义容器里，所有针对它的样式都带上容器前缀：
/* 只作用于特定容器内的jQuery UI组件，避免影响OOUI */
.my-jqui-scope .ui-button {
background: #e6e6e6;
border: 1px solid #d3d3d3;
}
/* 同理，OOUI组件的样式也限定在自己的容器中 */
.my-ooui-scope .oo-ui-buttonElement-button {
border-radius: 2px;
}
/* 提高优先级，抵抗后加载的reset */
.my-jqui-scope .ui-dialog .ui-button {
background: #e6e6e6 !important;
}反方向的防护同样重要。OOUI自身的样式是按.oo-ui-前缀组织的，冲突概率低，但如果你使用了第三方jQuery UI主题（比如老版的Redmond或Smoothness定制版），要检查主题文件里是否有不带ui-前缀的通配规则，有的话需要手工裁剪。一个省事的验证方法是临时禁用其中一个样式表，观察组件外观是否恢复正常，快速定位污染源。
如果条件允许，还可以在ResourceLoader模块定义里显式声明样式依赖关系，让加载器按正确顺序输出。在extension.json中：
// extension.json 片段，声明依赖与样式位置
"ResourceModules": {
"ext.myext.jqui": {
"scripts": [ "ext.myext.jqui.js" ],
"styles": [ "styles/jquery-ui-overrides.css" ],
"dependencies": [ "jquery.ui" ]
},
"ext.myext.ooui": {
"scripts": [ "ext.myext.ooui.js" ],
"dependencies": [ "oojs-ui-core" ]
}
}把覆盖样式放在依赖jQuery UI的模块里，加载器会保证它在基础主题之后输出，优先级天然正确，就不需要到处写!important了。
长期治理：逐步收敛到单一组件库
上面的手段都是止血方案，本质上是让两套库共存。从长期维护角度看，更健康的路径是逐步收敛。MediaWiki核心已经全面转向OOUI（以及更新的Codex体系），新功能建议一律使用OOUI，存量jQuery UI代码在迭代时逐步替换。替换时可以按组件对照迁移：datepicker换成mw.widgets.datetime相关的日期选择器，dialog换成OO.ui.WindowManager加OO.ui.MessageDialog，autocomplete换成mw.widgets.TitleSearchWidget。
迁移过程中建议在扩展里维护一个兼容层，把常用交互封装成统一接口，内部实现可以从jQuery UI切到OOUI而调用方无感知。同时利用MediaWiki的持续集成环境跑Selenium界面测试，覆盖关键交互路径，确保替换过程不引入回归。这样一来，短期内两套库和平共处，长期则能干净地完成技术栈升级，事件冲突和样式污染问题也就从根源上消失了。