如何在IBM WebSphere Portal中解决jQuery与Dojo在Theme Policy下的冲突并配置AMD加载器？

在WebSphere Portal主题开发中，jQuery与Dojo的冲突并不是简单的版本不兼容，而是Theme Policy对客户端模块的加载策略与两种框架自身模块机制叠加后的结果。Dojo作为AMD模块系统，会向全局环境注入define和require函数；jQuery则默认以全局函数jQuery和$暴露自身。当主题同时启用Dojo模块和jQuery插件时，后加载的框架会覆盖前者的全局符号，或在define未定义时导致模块解析失败。这些问题在Portal的Theme Policy管理下会更加隐蔽，因为主题中的模块声明和加载顺序由框架决定，开发者往往无法直接从页面脚本中观察。

要解决这类冲突，不能只靠调整代码顺序或粗暴禁用某个框架，而是需要理解Portal的模块注册机制，并利用AMD加载器的配置能力把jQuery纳入统一依赖管理。下面从冲突根源、加载器配置和整合验证三个层面展开。

冲突根源：Theme Policy如何放大jQuery与Dojo的全局符号竞争

WebSphere Portal的主题框架通过模块定义文件来声明页面所需的JavaScript和CSS资源，这些声明会被Theme Policy读取并合并成最终的资源输出。Dojo是Portal默认的基础库，其AMD加载器会在页面初始化阶段注册全局的define和require。如果主题中同时以传统方式引入jQuery，jQuery会直接在全局作用域绑定window.jQuery和window.$，本身不会与define冲突，但后续如果有jQuery插件内部调用define，就可能被Dojo的loader拦截，产生模块ID错误。

更常见的冲突发生在$符号上。Dojo的旧版模块或某些扩展会使用$作为查询函数的别名，而jQuery也会将$绑定到自身。当Theme Policy按照依赖顺序输出脚本时，如果jQuery在Dojo相关模块之后加载，$会被jQuery覆盖，导致依赖$的Dojo模块拿到的不是预期对象；反之，如果Dojo的$后加载，jQuery的$又可能失效。这种符号覆盖在开发环境下可能偶发，在合并压缩后的生产环境则稳定出现，排查起来十分困难。

下面是一个典型的不合理模块声明，同时加载Dojo和jQuery但没有处理依赖关系，容易触发上述问题：

<module>
  <id>myThemeModules</id>
  <dependency>
    <url>/wps/portal_dojo/v1.9/dojo/dojo.js</url>
  </dependency>
  <dependency>
    <url>/themes/myTheme/js/jquery.min.js</url>
  </dependency>
</module>

上述配置把两条脚本按顺序输出，但完全没有告诉Portal二者之间存在AMD依赖关系。当后续业务脚本使用define或require时，加载器无法判断jQuery是否已就绪，导致模块解析异常。

AMD加载器配置：将jQuery包装为受控模块并释放全局占用

核心思路是不再把jQuery当作游离的全局脚本，而是通过AMD加载器将其声明为一个标准模块。Dojo的加载器支持加载非AMD脚本，只要在依赖声明后用factory函数返回全局对象即可。为了让jQuery与Dojo共存，可以在加载jQuery后立即调用noConflict，把$交还给Dojo或其他占用者，同时将jQuery对象作为模块返回值保存。

下面的代码定义了一个名为jquery的AMD模块，它先加载原始jQuery文件，再通过noConflict(true)释放全局$和jQuery变量，最后返回jQuery构造函数供后续模块使用：

define([
  'dojo/_base/config',
  '/themes/myTheme/js/jquery.min.js'
], function(config, jQuery) {
  // 释放全局占用，避免与Dojo或其他库冲突
  var localJQuery = jQuery.noConflict(true);
  window.jQuery = localJQuery;
  window.$ = localJQuery;
  return localJQuery;
});

在Portal主题的模块声明中，需要把上面的模块定义注册为一个模块ID，并让其他业务模块通过依赖引用它。这样jQuery的加载时机由加载器统一控制，不会与Dojo的define产生竞争。还可以利用Dojo的require配置中的paths或aliases，把jQuery映射到具体URL，减少硬编码路径。

另一个需要注意的点是：不要同时使用多个AMD加载器。如果页面中既引入了RequireJS又使用Dojo的加载器，define和require会被反复覆盖，jQuery模块可能被错误加载两次。WebSphere Portal默认使用Dojo加载器，因此应当统一使用Dojo的define/require，而不是再引入RequireJS。

整合步骤与验证：在Portal主题中落地并检查加载链

实施时可以按以下顺序操作：首先在主题的模块定义文件中添加jQuery的AMD包装模块，并声明其依赖的Dojo配置模块；然后在需要jQuery的业务模块中通过define依赖注入jquery；最后调整Theme Policy中的模块合并顺序，确保Dojo加载器先于所有使用define的脚本初始化。Portal的模块框架支持在theme.html中通过贡献点添加模块，也可以直接编辑模块XML。

验证阶段可以在浏览器控制台执行以下脚本，检查全局符号和模块状态：

console.log('define type:', typeof define);
console.log('require type:', typeof require);
console.log('jQuery version:', window.jQuery ? window.jQuery.fn.jquery : 'missing');
console.log('$ is jQuery:', window.$ === window.jQuery);
require(['jquery'], function($) {
  console.log('AMD loaded jQuery:', $.fn.jquery);
});

如果控制台显示$不等于window.jQuery，说明$被其他模块占用，需要检查Dojo的$使用场景并决定是否需要在业务代码中改用jQuery变量而非$。如果define为undefined，说明Dojo加载器未初始化，应检查主题模块声明中的加载顺序。如果AMD加载的jQuery版本与全局版本不一致，说明jQuery被重复加载，需要清理直接引入的脚本标签。

为了便于后续维护，可以在主题中建立一个统一的模块注册文件，把所有第三方库都包装成AMD模块，避免在页面中散落<script>标签。同时利用Portal的调试模式（在URL中添加Debug参数）查看模块加载链，定位重复加载或缺失依赖的问题。这样不仅能解决jQuery与Dojo的冲突，还能提升整个主题资源加载的可控性和性能。

IBM WebSphere PortaljQuery与Dojo冲突AMD加载器配置修改时间：2026-09-30 01:38:07