イベントターゲットとリスナ登録の内部モデル

EventTarget は「リスナの台帳」を持つ

addEventListener は「関数をどこかに渡しておく魔法」ではありません。DOM 仕様では、EventTarget を実装するすべてのオブジェクト（Element・document・Window・XMLHttpRequest・AbortSignal など）が、内部に イベントリスナリスト（event listener list） という台帳を持つ、と明確に定義されています。addEventListener はこの台帳に1行追記する操作、removeEventListener は1行削除する操作にすぎません。

この台帳の各エントリが何で構成され、どの項目で「同じリスナ」と判定されるかを知ると、現場で頻発する「同じ関数を2回登録したのに1回しか呼ばれない／逆に2回呼ばれる」「removeEventListener で消えない」「once を付けたのに残る」といった現象が、すべて仕様どおりの帰結として説明できます。伝播の経路そのものは ブラウザイベントの伝播モデル で扱うので、ここでは登録と管理の内部モデルに絞ります。

リスナエントリの構造と同一性の判定

台帳の1エントリは、概念的に次のフィールドを持ちます。

ここが核心です。同じリスナかどうかは (type, callback, capture) の3項目だけで決まり、once・passive・signal は判定に一切関与しません。仕様の add 手順は明示的にこう述べます。「listener list に、type が等しく、callback が等しく、capture が等しいエントリが既に存在するなら、何もしない（追加しない）」。つまり重複登録は黙って捨てられるのであって、エラーにもならず、2件にもなりません。

function onClick() { console.log('hi'); }

el.addEventListener('click', onClick);            // 1件目: 追加される
el.addEventListener('click', onClick);            // (type,callback,capture) 一致 → 無視
el.addEventListener('click', onClick, { once: true }); // once 違いでも判定に含めない → 無視
// 結果: リスナは1件だけ。click 1回につき onClick は1回呼ばれる

匿名関数が消せない理由

removeEventListener も同じ (type, callback, capture) の一致でしか動きません。3項目が完全一致するエントリを台帳から探し、あれば削除、なければ何もしません（これもエラーになりません）。したがって「消すには、登録時とまったく同じ関数参照と同じ capture を渡す」のが絶対条件です。

// アンチパターン1: 匿名関数は参照を保持できない
el.addEventListener('click', () => doStuff());
el.removeEventListener('click', () => doStuff()); // 別の関数オブジェクト → 一致せず消えない

// アンチパターン2: bind() は毎回新しい関数を返す
el.addEventListener('click', handler.bind(this));
el.removeEventListener('click', handler.bind(this)); // 別物 → 消えない

// 正しいパターン: 参照を変数で固定する
const bound = handler.bind(this);
el.addEventListener('click', bound);
el.removeEventListener('click', bound);             // 同一参照 → 消える

bind()・アロー関数・function リテラルは、評価のたびに新しい関数オブジェクトを生成します。これらは値として等しく見えても参照が異なるため、同一性判定（参照の同値比較）を通りません。クラスでハンドラを使うなら、コンストラクタで一度だけ this.onClick = this.onClick.bind(this) して参照を固定するのが定石です。

once／passive の内部効果

once: true は、リスナが1回呼ばれたら台帳から自動削除される指定です。仕様では、コールバックを呼ぶ手順の中で「once が真なら、コールバックを実行する直前にこのリスナを listener list から除去する」と定義されており、removeEventListener を自分で呼ぶのと同じ効果が自動で起きます（除去が実行の直前なので、ハンドラ内で同じイベントが再ディスパッチされても二重には呼ばれません）。注意点は、once でも一度も呼ばれないうちは台帳に残ること。一度も発火しないまま要素ごと破棄される場合、once は解除の役には立ちません。

passive: true は「このリスナは preventDefault() を呼ばない」というブラウザへの約束です。台帳エントリの passive フラグが真なら、ディスパッチ中にそのリスナ内で preventDefault() を呼んでも無視され（コンソール警告が出る）、ブラウザはリスナの完了を待たずにスクロール等の既定動作を進められます。touchstart・touchmove・wheel でスクロール性能に効くのはこのためです。once と同様、passive も同一性判定には関与しないので、passive 違いで重複登録し直すことはできません。

signal による宣言的な一括解除

signal オプションは比較的新しく、AbortSignal を渡しておくと、その signal が abort された時点でリスナが自動的に外れる仕組みです。仕様の add 手順では、signal が渡されたとき、その signal に「abort されたらこのリスナを listener list から除去する」というアルゴリズムを登録します。これにより、複数のリスナを1つのコントローラでまとめて解除できます。

const controller = new AbortController();
const { signal } = controller;

window.addEventListener('resize', onResize,  { signal });
window.addEventListener('scroll', onScroll,  { signal });
document.addEventListener('keydown', onKey,  { signal });

// 3つすべてを1行で解除（参照を1つずつ保持する必要がない）
controller.abort();

これは「removeEventListener を3回呼ぶ」と等価ですが、個々の関数参照を覚えておく必要がない点が決定的に楽です。コンポーネントのアンマウント時に controller.abort() を1回呼ぶだけで、そのコンポーネントが張った全リスナを確実に剥がせます。さらに fetch の中断にも同じ signal を使い回せるため、fetch のキャンセルとリスナ解除を1つのライフサイクルに束ねられます。同じ AbortSignal の仕組みは Fetch API の内部設計 でも中心的に使われています。

ディスパッチ時のスナップショット

もう一つの重要な内部規則が、ディスパッチ開始時にリスナリストのコピー（スナップショット）を取ることです。あるイベントを配送している最中に、リスナの中で同じ type のリスナを新たに追加しても、その新リスナは今回のディスパッチでは呼ばれません。逆に、実行中に削除したリスナは、まだ呼ばれていなければ今回呼ばれなくなります（スナップショットを走査しつつ、各リスナ実行直前に「除去済みか」を確認するため）。

el.addEventListener('click', function a() {
  // a の中で同じ click に b を足しても、今回のクリックでは b は呼ばれない
  el.addEventListener('click', function b() { console.log('b'); });
});
// 次回のクリックからは a → b の順で両方呼ばれる

この規則があるおかげで、リスナ内でリスナを足し引きしても当回の走査が無限ループや不定挙動に陥らないことが保証されます。once の自動削除や signal による除去も、この「実行直前の除去確認」と整合して働きます。

まとめ