做 Vue 全端時，TypeScript 真正幫到我的地方
我是後端出身，但很多專案是我一個人從 API 寫到畫面，前端用 Vue。一開始我對 TypeScript 沒什麼感覺，覺得是多打很多字。真正讓我離不開它的，不是那些花俏的型別體操，而是它在「前後端之間」幫我擋掉的一整類低級錯誤。這篇講的是務實的體會，不是型別系統的炫技。
它最大的價值：前後端的契約
對全端來說，TypeScript 最有感的地方是讓前端和後端對齊。後端回什麼樣的資料、欄位叫什麼、可不可以是 null——這些用型別寫清楚之後，前端拿錯欄位、把字串當數字用這種錯誤，在編輯器裡就紅起來，根本進不到執行階段。
我會把 API 的回應型別定義好，前端整條資料流都吃這個型別。後端改了欄位，前端對不上的地方立刻被標出來。這在「一個人兼顧前後端」時，省下大量「咦怎麼是 undefined」的除錯時間。
我真正常用的型別功能
不需要把型別系統玩得很深，幾個基礎工具就涵蓋我九成的需求：
- 介面／type 定義資料形狀：把 API 回應、表單資料的結構寫清楚，這是基本盤
- 聯合型別與字面量：例如訂單狀態只能是那幾個值，打錯一個字就報錯，比用魔術字串安全太多
- 泛型：主要用在共用的工具上，例如包一個 API 呼叫函式，讓回傳型別跟著傳入的型別走
- 工具型別（Partial、Pick、Omit）：從既有型別衍生新型別，例如「更新時只送部分欄位」就用 Partial，不用重寫一份
我刻意克制不去寫那種「看起來很厲害但沒人看得懂」的條件型別巢狀。型別是用來幫人讀懂程式、擋掉錯誤的，不是拿來炫的。團隊裡別人看不懂的型別，就是負債。
寧可嚴格
我會把 strict 模式打開，尤其是嚴格的 null 檢查。它強迫你正面處理「這個東西可能不存在」——也就是前端最常炸的那個 undefined。一開始會被逼著多寫一些判斷，但那些判斷本來就該寫，只是以前你都靠運氣。
any 是逃生門，不是常態
趕時間時偶爾用 any 我不反對，但它會像破洞一樣讓型別檢查整段失效。我的原則是：用 any 當下就標記為待還的技術債，有空就把它換成正確的型別。一個專案 any 滿天飛，就等於沒在用 TypeScript。
在 Vue 裡的體會
Vue 對 TypeScript 的支援這幾年成熟很多。我最有感的是元件的 props 有型別——傳錯參數、少傳必填的，編輯器直接擋。搭配集中管理的狀態，整個前端的資料流都在型別保護之下，重構時的安全感完全不一樣。
小結
對一個後端背景的全端工程師，TypeScript 的價值我會這樣總結：
- 最大的好處是讓前後端對齊，把一整類「拿錯資料」的錯誤提早到編輯期
- 用好基礎功能（介面、聯合型別、泛型、工具型別）就夠，別玩型別體操
- 開 strict、認真處理 null，那才是前端最常炸的地方
- any 是暫時的逃生門，不是常態
TypeScript 對我來說不是「多打字」，是「把未來會花在除錯上的時間，提前一點點付清」。對要一個人扛前後端的人，這筆交易非常划算。