宙斯浏览器扩展依赖冲突表现为图标灰显、功能失效及控制台报错，根源是多扩展重写同一全局对象或注入同名脚本；可通过禁用扩展、倒序排查、隔离测试、修复manifest声明及清除残留缓存来定位与解决。
宙斯浏览器扩展依赖冲突表现为插件图标灰显、功能按钮失效、控制台报错“ReferenceError: xxx is not defined”或“Failed to load resource: net::ERR_BLOCKED_BY_CLIENT”，根源是多个扩展同时尝试重写同一全局对象（如window.fetch、XMLHttpRequest）或注入同名content script，导致脚本执行链断裂。
快速验证是否为依赖冲突
第一步：在地址栏输入zeus://extensions并回车，进入扩展管理页。
第二步：点击右上角“开发者模式”开关启用调试能力。
第三步：逐个禁用除目标插件外的所有扩展→关闭全部标签页→彻底退出宙斯进程（Windows任务管理器结束zeus.exe，macOS活动监视器强制退出）→重启浏览器→访问原页面测试功能是否恢复。
若此时插件恢复正常，说明存在依赖冲突；若仍异常，则问题不在扩展间依赖，需转向manifest或权限排查。
定位具体冲突扩展组合
方法一：按加载顺序倒序禁用
① 记录当前所有已启用扩展的排列顺序（从上到下）；
② 从列表最底部开始，每次禁用一个扩展→重启浏览器→测试；
③ 当禁用某个扩展后功能突然恢复，该扩展即为被依赖方，而它上方紧邻的扩展极可能是冲突触发者——因为宙斯按列表顺序注入content script，后加载的脚本会覆盖先加载的同名函数。
这一步必须严格按顺序操作，跳过中间项会导致误判。
方法二：隔离关键依赖模块
只保留目标插件 + 一个疑似依赖项（如广告拦截器、脚本管理器、字体替换工具）→重启测试；
若失败，换另一个依赖项重复测试；
若成功，再加入第三个扩展，逐步叠加，直到复现失败；
【注意】每次叠加后必须彻底重启，否则旧注入脚本仍在内存中运行。
修复 manifest.json 中的依赖声明
若目标插件需调用Tampermonkey暴露的unsafeWindow或GM_* API，但manifest.json未声明依赖关系，宙斯将拒绝注入上下文。
打开插件解压目录下的manifest.json文件：
搜索"content_scripts" → 在其数组内任一项中添加"run_at": "document_idle"；
在根对象层级添加"externally_connectable": {"matches": ["*://*/*"]}
若插件明确依赖Tampermonkey，则必须在"permissions"中加入["scripting"]，并在"host_permissions"中补全["*://*/*"]；
【缺失scripting权限=无法调用chrome.scripting.executeScript】。
清除残留注入脚本缓存
扩展卸载后，其注入的全局变量（如window.__adguard、window.$crx_tampermonkey）可能仍驻留内存，新扩展调用时直接报ReferenceError。
关闭所有宙斯窗口→打开任务管理器确认无zeus.exe残留→进入用户数据目录：
Windows路径：%AppData%\ZeusBrowser\User Data\Default\Extensions\
macOS路径：~/Library/Application Support/ZeusBrowser/Default/Extensions/
将整个Extensions文件夹重命名为Extensions_backup→重启浏览器→重新启用必要扩展。
