回答。

質問の歴史

TypeScriptは多くのオブジェクト指向言語とは異なり、構造的型付け（ダックタイピング）を実装しています：オブジェクトは必要なすべてのプロパティを持っている場合に型に適合すると見なされ、その型が明示的に宣言されているかどうかは問われません。

問題

この柔軟性は、構造が一致する場合にオブジェクトが型として受け入れられることを引き起こすことがありますが、実際にはそれらは意味的に関連していない場合があります。これは、構造が偶然一致する複雑なデータモデルの際に危険です。

解決策

常にオブジェクトのタイプを正しく構造化し、異なるエンティティの構造の一致を最小限に抑え、重要な場合には「名義化」のために追加のプロパティやシンボルを使用します。

コード例：

interface Point { x: number; y: number; }
interface Pixel { x: number; y: number; }

function drawPoint(p: Point) {
  console.log(p.x, p.y);
}

const pixel: Pixel = { x: 1, y: 2 };
drawPoint(pixel); // OK, 構造的に互換性あり

主な特徴：

型名ではなく、構造（プロパティとその型）によるチェック
既存のJSコードとの統合が容易
意味的に異なるオブジェクトの構造が一致した際の可能性のあるコンフリクト

罠のある質問。

2つのインターフェースの構造が一致する場合、それは完全に相互に置き換え可能であることを意味しますか？

構造的には可能ですが、プログラムの論理的にはそうではありません。これはコンパイラのレベルで許容されますが、論理エラーを引き起こす可能性があります（たとえば、上記のPointとPixel）。

特定の型に対して構造的互換性を禁止することはできますか？

完全にはできませんが、ユニークなプロパティ（たとえば、シンボルを使用して）を追加することはできます：

interface Brand {
  _brand: unique symbol;
}

これで、別のオブジェクトは同様のユニークなシンボルなしにこの型を模倣できません。

構造的型付けは名義型付けとどう異なりますか？

構造的型付けは構造の有無に基づき、名義型付けは特定の名前空間における型名の一致に基づきます。TSでは、デフォルトで常に構造型付けです。

型の誤りとアンチパターン

同じ構造の無関係なオブジェクトを誤って受け入れる
シグネチャが完全に一致する — 概念的に異なる型を区別できない
型の安全性に関する誤った感覚

実生活の例

ネガティブケース

いくつかのエンティティで不本意にフィールドが一致した（たとえば、UserとAdminが{id: number, name: string}のように）、これがAPI契約の取り扱いで混乱を引き起こしました。

利点：

コードが少なく、新しいエンティティを拡張するのが簡単

欠点：

コンパイラが見逃す論理エラーを追跡するのが難しい

ポジティブケース

同じ構造を持つ意味的に異なる型を区別するためのユニークな「ラベル」シンボルや非標準のフィールドを使用します。