现在扩展更好的 5 个原因
新规则优先方案
过去，我们对规则有 4 个不同的优先级，但没有指定特定组内规则的选择和优先级。通过我们的新方案，我们根据规则包含的修饰符来计算规则的权重。这些修饰符按优先级排列（从最低到最高），它们对规则范围的影响决定了它们对整体优先级的值。这种新方法允许在转换阶段为规则设置声明性优先级，这在新的 MV3 中特别有用。有关新优先级方案的更多详细信息，请参阅我们的知识库。
兼容性$badfilter
修改器$badfilter有权禁用任 澳大利亚电报数据库 何其他规则。它的工作原理如下：过滤器开发人员有权禁用任何其他规则。它的工作原理如下：过滤器开发人员添加带有此修饰符的规则，当扩展程序收到动态更新时，带有修饰符的规则$badfilter优先于应用它的规则。
过去，无法禁用 MV3 中先前添加的规则。因此，我们首先$badfilter仅添加对同一文件中已存在的规则的支持。如果您在一篇文章中有一条规则并将其添加$badfilter到另一篇文章中，则它将不起作用。
然而，由于扩展开发人员的反馈，W3C 工作组列出并引入了一个新的 API，允许禁用其他声明性规则。这是我们在所有文件中添加$badfilter对所有规则的支持的最初动力。为此，我们重新设计了规则转换方案，为过滤器生成额外的元数据并查找应动态禁用的规则。
修改器支持$cookie
该修饰符$cookie允许您指定 cookie 的生存时间（离开时间或 TTL）。 MV3目前的功能还不足以让这个修改器正常工作，所以我们做了一些改进：
如果 MV3 API 足以使过滤规则发挥作用，我们会将其转换为声明性规则并将其添加到静态规则配置中。
否则，我们会在 TSUrlFilter 过滤器机制中额外处理 cookie，并使用 browser.cookies API 删除不应设置的 cookie 或缩短 cookie 的生命周期。
修饰符支持$elemhide, $generichide,$specifichide
这些修饰符帮助我们禁用某些网站的外观过滤规则。 MV3 还没有这些工具，因此我们通过 TSUrlFilter 过滤机制添加了对修饰符的支持。此机制创建扩展规则和阻止规则之间的兼容性，仅将排除的规则发送到内容脚本。
和其他一切
我们支持以下修饰符：
$method将规则的范围限制为使用指定 HTTP 方法集的请求。
$to将规则的范围限制为对指定域及其子域发出的请求。