Typecheck

檢查 TypeScript 型別是否正確。

先用一句話理解

檢查 TypeScript 型別是否正確。

打個比方

像在出貨前確認每個插頭規格都對。

什麼時候會遇到

使用 TypeScript 的專案在提交與部署前都應該跑。

再往深一點看

Typecheck 是由 TypeScript 編譯器（tsc）執行的靜態分析——它不執行你的程式碼，只讀取型別宣告，找出「這個函式預期收字串，你卻傳了數字」、「這個物件可能是 undefined 但你沒有處理」這類邏輯矛盾。Typecheck 和 build 是不同的步驟：有些 build 工具（例如 Vite，底層用 esbuild）為了速度只做轉譯、跳過型別檢查；但 Next.js 的 next build 預設會跑 tsc，型別有錯就會讓 build 失敗（除非在 next.config.js 設定 typescript.ignoreBuildErrors: true 刻意略過）。即便 build 工具會幫你跑型別檢查，獨立跑 typecheck 仍有價值——它能在不需要完整 build 的情況下快速驗證，也讓 CI 流水線有明確的把關步驟。開發時編輯器（如 VS Code）會即時顯示紅色波浪線，但那是本地提示，CI 裡明確跑 tsc --noEmit 才算正式納管。

舉個例子

你的 API 回傳 userId 是 string，但你的函式宣告它接收 number，Typecheck 會在你 push 之前就標出這個錯誤。在 GitHub Actions 裡設定 npm run typecheck 當成 CI 必跑步驟，確保這類型別錯誤不會悄悄進入 main branch。

常見誤解

- 到處用 any 型別繞過型別錯誤（例如 as any 或 // @ts-ignore），問題表面上消失，實際上只是把炸彈藏起來，等到 runtime 才爆出 undefined is not a function。
- 以為 build 成功就代表型別沒問題——使用 Vite 等跳過型別檢查的 build 工具時確實如此；但即便用 Next.js（next build 預設跑 tsc），仍應該在 CI 獨立跑 typecheck，這樣不需要等完整 build 就能快速把關。
- tsconfig.json 的 strict 模式是關的，等到哪天打開時才發現整個專案積累了幾百個型別錯誤要一次修完。