Tampermonkey（对于大多数浏览器）和 Greasemonkey（对于 Firefox）都支持@match and @include指令。
当我开始阅读它们之间的区别时，结果发现@match有点严格：用户脚本不会在某些地址上启动，这可能被认为是潜在危险或只是不需要的。
- https://wiki.greasespot.net/Include_and_exclude_rules https://wiki.greasespot.net/Include_and_exclude_rules
- https://wiki.greasespot.net/Metadata_Block#@match https://wiki.greasespot.net/Metadata_Block#@match
由此产生了一个问题：
a) 有吗启动的任何潜在风险my own用户脚本上all地址 (i.e. @match *://*/*和同样的@include)?
或者，b）在某些地址上启动用户脚本的限制仅与第三方用户脚本，即从某些网站下载的用户脚本，因此可能包含一些恶意代码？
在所有地址上运行您自己的用户脚本是否存在潜在风险？是的，一个小的；见下文。
（目前）不运行的主要原因your own所有页面上的用户脚本是：
-
浏览器性能：加载和运行脚本需要时间、CPU 周期，有时还需要磁盘访问。通常情况下，延迟很难被察觉，但如果它没有执行有用的服务，为什么还要延迟呢？
-
意外的副作用：你认为你的
$(".someclass").remove();代码只影响X页——直到它不影响为止。抓耳挠腮，然后是随意的咒骂……
其他常见的副作用包括导致页面或用户脚本失败的脚本冲突 https://stackoverflow.com/questions/15171769/jquery-conflict-between-greasemonkey-script-and-page.
-
iframes:默认情况下，脚本在 iframe 上运行，并且某些页面具有数十个 iframe 和/或嵌套了多个级别的 iframe。
这是性能和副作用问题的乘数。
-
风险：敏感代码泄露： Use
$.get( "frbyPlay.me/pics?user=admin&pw=1234"...，在非沙盒代码中，错误的站点可以看到它（或 AJAX）。
当使用页面的JS时，攻击的途径是无限的。幸运的是，这通常风险很低并且很容易缓解，但无知或自满可能会导致严重的尴尬。
-
风险：接触“绝命毒师”：最近，一个以前深受喜爱和信任的扩展变成了邪恶 https://bugzilla.mozilla.org/show_bug.cgi?id=1472948.
当您的脚本使用的某些库（例如 jQuery）被黑客攻击或“商业优化”时会发生什么？脚本运行的页面越少，恶作剧的机会就越少，造成的损害也就越小。
（当然，如果 Tampermonkey 本身也留过山羊胡子，那么无论如何我们都会被打败。）
请注意，原因 1 和 2 也是您应该使用的原因@match尽可能多地而不是@include. @match解析网址的速度更快，并且在不需要/意外的网站上触发的可能性也大大降低。
（而且，在 Tampermonkey 中，@match在 Tampermonkey 仪表板中添加这些小站点图标。）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
