ユーザースクリプトの@includeと@matchの違いは何ですか？
メタデータブロックのGreaseSpotページ は、2つは非常に似ていると述べていますが、@matchは「*文字が何を意味するかについてより厳密なルールを設定します。」次に、GreaseSpotは@includeを使用して teach に進みますが、Chrome this のような例は通常@matchを使用しているようです@includeは互換性の目的でのみサポートされていることを示し、@matchが推奨されます。
どうやら 、@include google.*はgoogle.evil.comで実行できますが、@match google.*は実行できません。
これらの1つの例では、ワイルドカードがこれら2つの間でどのように異なる動作をするかを実際に確認するには不十分であり、ここでの回答にはより良い説明が求められています。
新しいGreaseMonkeyスクリプト（Firefox）はデフォルトで@includeを使用しますが、新しいTamperMonkeyスクリプト（Chromeなど）はデフォルトで@matchを使用します。
これら2つの違いは何ですか？
たとえば、それぞれがワイルドカードをどのように処理しますか？
ブラウザ間の互換性に違いはありますか？
誰かがどちらを使用するかを選択する理由は何ですか？
@matchで正規表現を使用することはできませんが、@ includeで can を使用することはできます。
ただし、@ includeを使用すると、スクリプトがすべてのサイトに適用されることについて、ユーザーに恐ろしいセキュリティ警告が表示されます。
これは、@ include式を使用すると、スクリプトが適用されるサイトについてより制限できるようになります（たとえば、URLの一部を数値で指定することで、正規表現フラグメント「[0-9] +」、または「^ https？：//」を使用して、これらの2つのスキームのみでスクリプトに適用します。 @match。これにより、スクリプトがより広く適用されます）。