为什么Safari浏览器在最新版本中取消了对某些旧版扩展的支持？

Safari 12 是一个分水岭——从这一版（2018年随 macOS Moja ve 发布）开始，苹果彻底抛弃了旧扩展架构，全面转向基于 Web Extensions 的新体系。旧扩展从此成为历史，无法兼容。

换句话说，如果你还在用着十年前的 Safari 扩展，打开新版浏览器后，它们就像消失了一样。这不是 bug，而是苹果刻意为之的“清理行动”。背后原因也不复杂：安全和性能的代价，已经超过了兼容性带来的便利。

扩展 API 彻底重构

新架构基于 Web Extensions 标准，API 被大幅收紧。曾经旧扩展赖以生存的接口——像 safari.application、safari.browserWindow 这类——被彻底移除。扩展再也无法随意读取网页数据，能访问的范围被严格限定。打个比方：以前扩展像个“自由人”，想进哪个房间就进哪个；现在必须申请门禁卡，而且只能进指定的房间。

安全与隐私策略升级

苹果把“最小权限原则”写进了审核规范，这不是空话：

• 旧扩展常常能读取全部网页内容、监听所有标签页、随意修改 DOM——这等于把用户隐私的钥匙直接交给开发者。
• 新架构要求扩展明确声明所需权限，比如“只对特定域名生效”或“只读取选中的文本”。系统级沙盒把扩展圈定在独立空间，越界行为会被直接拦截。
• 更关键的是，未经 App Store 审核的旧扩展无法通过 Gatekeeper 验证，macOS 默认拒绝加载——这道门直接关死了。

统一分发与维护控制

苹果将扩展纳入 Mac App Store 生态管理，背后的逻辑很清楚：

• 所有上架扩展必须签名、沙盒化、定期更新，方便漏洞响应和版本回滚——出了问题能精准定位，也能快速修复。
• 而旧扩展大多是独立的 .safariextz 文件，开发者可以随意分发，苹果根本没法监管后续安全性。用一句行业里的话说：这就像“黑箱操作”，谁都不知道里面的代码后来有没有被篡改。
• iOS 13 起，旧扩展直接被禁用；macOS 后续版本也在逐步收紧（比如 Ventura 开始默认不显示未签名扩展）。趋势很明确：旧架构彻底退出历史舞台。

性能与稳定性优化

如果你经历过 Safari 频繁崩溃或页面卡顿，很可能就是旧扩展惹的祸——它们常驻内存、无节制注入脚本，是常见元凶：

• Safari 12+ 引入了扩展进程隔离机制：单个扩展崩溃不会拖垮整个浏览器，就像大楼里一户人家断水，不影响整栋楼。
• 旧扩展缺乏资源配额限制，一个脚本就能吃光渲染引擎的计算能力。新架构下，每个扩展的资源消耗被严格监控。
• 苹果在兼容性提示中直言：“此扩展可能降低浏览速度”——这可不是营销话术，而是技术底层的真实判断。如果你观察过旧扩展的内存占用曲线，就会知道这话一点不夸张。