В чем разница между @include и @match в пользовательских сценариях?

Question

GreaseSpot page on metadata blocks говорит, что эти два очень похожи, но @match "устанавливает более строгие правила в отношении символа *". Затем GreaseSpot переходит к teach с использованием @include, но примеры Chrome, такие как this, как правило, используют @match и указывают, что @include поддерживается только в целях совместимости; @match.

Apparently, @include google.* может работать на google.evil.com, а @match google.* не может.
Этот пример недостаточен, чтобы действительно увидеть, как подстановочные знаки ведут себя по-разному между этими двумя, и более подробные объяснения запрашиваются здесь.

Новые сценарии GreaseMonkey (Firefox) используют @include по умолчанию, а новые скрипты TamperMonkey (например, Chrome) используют по умолчанию @match.

В чем же разница между этими двумя?

Например, как каждый из них управляет шаблонами?
Существуют ли различия в кросс-браузерной совместимости?
Какие причины у кого-то есть для выбора одного над другим?

Answer 1

Вы не можете использовать регулярные выражения с помощью @match, а вы - can с @include.

Тем не менее, @include предоставит вашим пользователям более страшные предупреждения о безопасности, применимые ко всем сайтам.

Это даже при том, что @include выражение позволяет вам быть более ограничительным о сайтах скрипт относится (например, указав, что часть URL быть числовой с использованием регулярных выражений фрагмента «[0-9] +», или используя «^ https?: //», чтобы применить к сценарию только эти две схемы, а не более общий оператор non-regex globbing *, используемый для каждого из этих случаев в @match, что заставляет скрипт применяться более широко) ,