Jasmine 7 加载 mock-ajax 报 getJasmineRequireObj 未定义

浏览器里的 describe、it 都能使用，加载 mock-ajax.js 时却报 getJasmineRequireObj is not defined。如果组合是 Jasmine 7 与 jasmine-ajax 4，应检查旧 Ajax 扩展依赖的内部装配入口。

Jasmine 7 改变了核心模块的启动与导出方式。旧 jasmine-ajax 4 使用 Jasmine 的内部模块系统装配自身，因此即使测试的公开全局函数已经存在，也不代表旧的 getJasmineRequireObj 仍可调用。把脚本加载顺序反复交换，不能补回已经移除的内部入口。

更新 Ajax 扩展，而不只更新核心

正式 jasmine-ajax 5.0.0 使用独立的 getAjaxRequireObj 装配器，并在浏览器中通过现有 jasmine 安装 Ajax 实例，不再要求那个旧的核心装配函数。使用 Jasmine 7 时，应沿项目兼容范围更新配套 Ajax 扩展，核对真正送入浏览器的文件版本。

已有测试仍按需要安装与卸载 Ajax 替身，例如：

beforeEach(() => jasmine.Ajax.install());
afterEach(() => jasmine.Ajax.uninstall());

这是已经正确加载 Jasmine 和对应 mock-ajax 资源后的用例接线，不负责加载脚本。jasmine 核心必须先可用，测试框架原来的启动、测试文件与 helper 顺序也要保留；不能把这两行放进脚本列表配置就期待它们执行。

配置路径正确，页面也可能仍加载旧资源

先从浏览器实际加载的 mock-ajax 内容或构建产物确认版本。项目的静态文件复制、runner 资源清单或缓存，可能仍保留 4.x 文件；package.json 更新并不自动证明浏览器请求已经改变。

同时检查是否出现两份 jasmine 核心或两套 Ajax 扩展。补一个全局 getJasmineRequireObj 函数，让旧扩展勉强启动，会把内部模块对象与真实测试环境的关系变得更难判断，也不是正式兼容方案。

如果工程必须留在旧扩展，应保存已验证的整套兼容组合，而不是随意拼接新核心与旧内部脚本。改动前保留资源列表与锁文件，撤回时一并恢复对应版本，避免只有其中一份文件回退。

验收应进入原来的浏览器 runner，确认脚本加载不再报错，Ajax 请求确实被拦截，桩响应触发原断言，卸载后下一用例没有继承旧请求记录。页面能打开、describe 存在，或测试没有真正发出请求，都不足以证明 Ajax 模拟已经恢复。