PT 助手 Plus 一个安装包通吃 Chrome、Edge 和 Firefox跨浏览器适配手段全拆解【免费下载链接】PT-Plugin-PlusPT 助手 Plus为 Microsoft Edge、Google Chrome、Firefox 浏览器插件Web Extensions主要用于辅助下载 PT 站的种子。项目地址: https://gitcode.com/GitHub_Trending/pt/PT-Plugin-PlusPT 助手 PlusPT-Plugin-Plus是一个同时面向 Chrome、Edge、Firefox 的浏览器扩展用于辅助 PT 站点的种子搜索与下载。本文基于其源码拆解它如何用一份 Manifest 和一套构建产物抹平三家浏览器的差异你看完能讲清同一个插件包在三个浏览器里各靠什么机制跑起来。先从一个真实烦恼说起做 PT 种子辅助插件等于要在三种环境里同时交付用户装的是 Chrome 还是 Firefox装完的功能必须一致。麻烦在于三家的规矩并不相同。Firefox 走 Add-on 渠道要求声明自己的更新地址而 Chrome 明确禁止在 Manifest 里出现update_urlChrome 对内容脚本的编码校验更严格第三方库里混进特殊字符就可能整包加载失败downloads、cookies这类敏感权限各商店的审核口径也不一样。换个角度想如果为每个浏览器维护一套代码PT 助手 Plus 的下载、签到、收藏功能就要写三遍。它的选择是一份代码 单份 Manifest 构建期修正下面按这个思路逐层拆。一张图看懂整体思路关键协作关系public/manifest.json是唯一一份清单通过浏览器专属字段声明 Firefox 特有能力webpack 在 webpack/common.js 里统一处理分包与压缩真正运行时的差异存储、消息通道则收敛到 src/service/localStorage.ts 和 src/service/extension.ts 两个小文件里业务代码对我现在跑在哪个环境完全无感。核心机制拆解一份 MV2 Manifest用专属字段各说各话为什么这么做Manifest V2 是三家都认的老标准一份清单天然能三端加载真正分叉的只是更新渠道和版本约束把它们塞进浏览器专属字段即可无需两份清单。实现上public/manifest.json 里和跨浏览器直接相关的字段就几处{ manifest_version: 2, minimum_chrome_version: 64.0.3242, browser_specific_settings: { gecko: { update_url: https://pt-plugins.github.io/PT-Plugin-Plus/update/firefox.json } }, permissions: [storage, contextMenus, notifications, ...], optional_permissions: [downloads, cookies] }browser_specific_settings.gecko只被 Firefox 解析Chrome 直接无视于是Firefox 必须有更新地址、Chrome 不能有这对矛盾在同一份文件里和平共处。另外optional_permissions把downloads、cookies挪出必选权限安装时不必向用户交代敏感用途用到下载功能时再单独申请——这是对各家权限审核策略的共同取巧。构建层替浏览器擦屁股你可能会问为什么 manifest 里 background 和 content 脚本要先加载一堆libs/*.js因为打包产物被拆成了第三方库和主程序两份而浏览器加载扩展脚本的顺序即执行顺序先载入库文件jQuery、types.expand 等才能保证主程序引用的全局对象存在。这个拆包规则写在 webpack/common.jssplitChunks: { chunks: all, cacheGroups: { vendors: { // 第三方库单独成 libs.js test: /[\\/]node_modules[\\/]/, name: libs }, // ... } }, minimizer: [ new TerserPlugin({ terserOptions: { output: { ascii_only: true } // 非 ASCII 字符转 \u 转义 } }) ]ascii_only这行注释写得很直白第三方库里的特殊字符曾让 Chrome 报该文件采用的不是 UTF-8 编码整包内容脚本加载失败。压缩时统一转成\uXXXX转义问题根除。同一文件里还有个细节minimize: !process.env.CHROME_WEB_STORE——上 Chrome 商店的包不压缩混淆方便商店审核时读代码本地包则正常压缩。运行时适配层同一个接口两套存储存储是最典型的同一接口两种后端。src/service/localStorage.ts 的构造函数先用window.chrome chrome.extension判断是否在扩展环境之后所有读写自动分流public set(key: any, value?: any, ...): Promiseany { return new Promiseany((resolve, reject) { if (this.isExtensionMode) { let data: any {}; data[key] value; chrome.storage.local.set(data, () resolve()); // 扩展环境走扩展存储 } else { if (typeof value ! string type EStorageType.json) { value JSON.stringify(value); } window.localStorage.setItem(key, value); // 普通网页走浏览器存储 } }); }上层业务调用APP.cache.set(...)时根本不知道数据落在chrome.storage.local还是window.localStorage。这套双后端还有个附带收益src/service/api.ts 用chrome.runtime取 manifest 里的options_ui.page拼出资源根路径取不到就退回chrome-extension://id调试模式下NODE_ENV test整个类退化为普通网页 本地服务http://主机:8001于是同一套选项页代码既能在扩展里跑也能在浏览器调试窗口里跑。消息通道的错误处理为后台页重载留后路内容脚本和后台页之间全靠chrome.runtime.sendMessage而 Chrome 在扩展更新或后台页重载后会抛出一类经典错误。src/service/extension.ts 的sendRequest对lastError做了模式匹配(result: any) { if (chrome.runtime.lastError) { let message chrome.runtime.lastError.message || ; if (/Could not establish connection/.test(message)) { // 后台页刚被重新加载连接建立失败 APP.showNotifications({ message: 插件状态未知当前操作可能失败请刷新页面后再试 }); reject(chrome.runtime.lastError); return; } // ...其他错误分支 } }这里不做重试、不静默吞错而是弹通知明确告知用户刷新页面再试。对工具类插件来说把失败说清楚比假装成功更可靠。自己动手验证克隆仓库后仓库地址https://gitcode.com/GitHub_Trending/pt/PT-Plugin-Plus可以这样跑通完整链路yarn dev # 产出 dist/背景脚本 内容脚本 选项页 资源然后打开chrome://extensionsFirefox 为about:debugging选加载已解压的扩展程序指向dist/。验证点有三个选项页能正常打开并读写配置说明存储适配层工作在任意 PT 站点页面触发搜索说明内容脚本注入成功把package.json里的dev:index模式打开后刷新扩展控制台应打印is extension mode.而直接访问调试页面时打印is not extension mode.正好对应适配层的两种分支。注意package.json里构建命令带了NODE_OPTIONS--openssl-legacy-provider老版 webpack 4 的新版 Node 下必须加这个参数才能启动。踩坑记录坑Chrome 加载内容脚本时报该文件采用的不是 UTF-8 编码Firefox 却正常 → 第三方库压缩产物混入非 ASCII 字符Chrome 校验更严 → 用 Terser 的ascii_only: true把非 ASCII 统一转义见 webpack/common.js。坑同一份 Manifest 在 Chrome 里装报字段错误提示不允许update_url→ Firefox 渠道强制要求更新地址Chrome 禁止 → 放进browser_specific_settings.gecko让各浏览器只读自己关心的字段。坑扩展自动更新后页面里的插件操作集体报Could not establish connection→ 后台页重载导致旧页面与新后台页的端口失效 → 在sendRequest中识别该错误文案并弹出请刷新页面通知不静默失败。坑downloads、cookies权限写死在permissions里商店审核和用户观感都差 → 移入optional_permissions功能触发时再经PPF.requestPermissions动态申请安装路径只保留最小权限集。坑新装 Node 后yarn dev直接崩报error:0308010C:digital envelope routines→ webpack 4 依赖的 md4 哈希被新版 OpenSSL 移除 → 在所有构建脚本前缀NODE_OPTIONS--openssl-legacy-provider用旧版算法兼容。写在最后PT 助手 Plus 的跨浏览器方案本质是清单声明期分工 运行时双后端 构建期修正没有为任何一家浏览器维护独立代码分支。README 显示 Firefox 渠道版本已下架后续演进大概率聚焦在 Manifest V3 迁移——后台页改 Service Worker、动态权限重新设计届时这套适配层值得再拆一次。【免费下载链接】PT-Plugin-PlusPT 助手 Plus为 Microsoft Edge、Google Chrome、Firefox 浏览器插件Web Extensions主要用于辅助下载 PT 站的种子。项目地址: https://gitcode.com/GitHub_Trending/pt/PT-Plugin-Plus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考