別再一股腦用 TypeScript 的 Interface 了
兩者功能高度重疊，于是問題來了：誰更好？
這篇文章會系統對比 type 與 interface，并解釋為什么在大多數場景里，你更應該優先選 type。
讓我們直接開始。
它們到底有啥差別？
先看一個最樸素的 “Person” 定義：
type Person = {
name: string
age: number
}
interface Person {
name: string
age: number
}乍看幾乎一樣——只不過 type 用 = 賦值出一個“形狀”，而 interface 直接聲明。
當然，區別不止于此。繼續往下拆。
可擴展性（Extensibility）
很多人會說：接口在“可擴展”上是天然贏家，因為它能用 extends 擴展其它接口：
// 接口擴展
interface Job {
job: string
}
interface Person extends Job {
name: string
age: number
}
const person: Person = {
name: 'John',
age: 25,
job: 'Full-Stack Web Developer',
}但 type 也能擴展——借助交叉類型 & 或聯合類型 | 做組合，而這是接口不能直接表達的：
// ? 可行：交叉類型拼裝
type Person = {
name: string
age: number
} & { job: string }
// ? 不可行：interface 不能在聲明處用交叉
// interface Person { ... } & { job: string }結論：如果你偏好“以類型運算搭積木”的風格，type 的表達力更強。
可實現性（Implementation）
在面向對象（OOP）世界，interface 支持被 class 用 implements直接實現，這點與 Java/C# 一致；而 type不能被類直接實現。
// OOP 實現示例
interface Work {
doWork: () =>void
}
class Person implements Work {
name: string
age: number
constructor(name: string, age: number) {
this.name = name
this.age = age
}
doWork() {
console.log('Working...')
}
}
const p = new Person('John', 25)
p.doWork()結論：如果你大量采用 class + implements 的編碼風格，interface 更順手；否則，type 足夠好用。
性能（類型檢查速度）
這里說的性能是 TS 編譯器的類型檢查。隨著代碼量增長，類型檢查耗時會顯著升高。 比較結果？沒有差別。社區與專家（如 Matt Pocock）已明確說明：**type 與 interface 在類型檢查性能上幾乎為 0 差異**。
選哪個，不影響編譯速度——放心用你喜歡的。
為什么 Interface 可能“埋雷”？
interface 有一個 Type 沒有的能力：聲明合并（Declaration Merging）。
編譯器會把同名接口自動合并：
// 初始聲明
interface Person {
name: string
age: number
}
// 追加聲明（合并）
interface Person {
gender: string
}
const someone: Person = { name: 'John', age: 25, gender: 'Male' }好處：無需改動源定義，就能給已有接口加字段。例如給第三方庫的接口“加料”，很方便。
壞處：可能帶來意料之外的行為：
- 聲明順序優先：后聲明覆蓋前聲明。分散在不同文件/依賴里時，容易出現不可預期的形狀。
- 與類的合并不安全：編譯器不會替你校驗屬性初始化，某些情況下可能留下運行時空值風險。
相對地，type是不可再聲明的，沒有“合并”這一套，因此更直觀、更可控。
何時用接口的合并？ ——擴展庫的公共接口（比如為
@auth/core的Session增補字段）是合理用法。除此之外，日常業務里濫用合并，容易踩坑。
快對照：什么時候用誰？
- 需要 class implements OOP 語義 →
interface - 需要 聲明合并（擴展三方庫接口） →
interface - 需要 聯合/交叉/條件類型 等類型運算，或者更靈活的組合表達 →
type - 追求可維護性、避免隱式變更，不希望同名合并 →
type - 關心編譯性能 → 兩者無差異，隨意
結論
除非你確實需要接口的特定能力（如 OOP implements 或對三方類型做聲明合并），否則在大多數日常場景里：
- **優先使用
type**：
表達力強（交叉、聯合、條件、映射等）
心智模型簡單（沒有合并副作用）
與接口在性能上等價
類型系統要的是“可預期”與“可維護”。 在這兩點上，type 更少“隱藏魔法”，更能讓你的團隊遠離因合并導致的灰色地帶。
