、性能真相與工程實(shí)踐)
1. 先說清一個(gè)誤區(qū)as const 優(yōu)化的到底是誰的性能我見過不少剛接觸 TypeScript 的同學(xué)一看到as const 性能總結(jié)這種標(biāo)題第一反應(yīng)是是不是給代碼提速用的是不是運(yùn)行的時(shí)候能省點(diǎn)內(nèi)存、少點(diǎn)計(jì)算其實(shí)完全不是。as const是純編譯期的類型標(biāo)記它不會(huì)生成任何一行運(yùn)行時(shí)代碼。你在源碼里寫const obj { name: admin } as const編譯產(chǎn)物依然是const obj { name: admin }字面量、括號(hào)、分號(hào)一樣都不會(huì)多。運(yùn)行時(shí)該多快還多快該占多少內(nèi)存還占多少內(nèi)存。這里沒有任何黑魔法也沒有任何性能優(yōu)化。那標(biāo)題里的性能究竟指什么我自己的理解是它優(yōu)化的是一種更高維度的性能——類型系統(tǒng)的工作性能和開發(fā)者的使用性能。展開說有三層第一層是類型推導(dǎo)的準(zhǔn)確率。沒有as const的時(shí)候TypeScript 面對一個(gè)對象或數(shù)組為了照顧你可能會(huì)改它這種可能性會(huì)把屬性拓寬成string、number這種寬泛類型。一旦你在后續(xù)代碼里需要精確到某個(gè)字面量值類型檢查器就得靠你手動(dòng)寫類型斷言去補(bǔ)充信息或者靠各種繞來繞去的判斷去猜。這個(gè)過程既費(fèi)腦也費(fèi)編譯期的推理時(shí)間。as const直接把最精確的類型告訴檢查器后面所有檢查都基于一個(gè)已知答案展開推理成本反而低。第二層是開發(fā)者的時(shí)間性能。最直觀的表現(xiàn)是你少寫一大堆重復(fù)的類型聲明。比如明明有個(gè)狀態(tài)常量表你卻要在旁邊再維護(hù)一份聯(lián)合類型改一處漏一處是家常便飯。as const讓值和類型同源改一處全局生效開發(fā)效率完全是另一回事。第三層是長期的維護(hù)性能。項(xiàng)目規(guī)模上去以后最大的開銷其實(shí)是改一個(gè)常量要找遍所有引用。用as const把常量表做成類型源頭改配置即改類型TS 編譯器會(huì)替你把所有不匹配的調(diào)用點(diǎn)揪出來。對比起來手寫聯(lián)合類型那種編譯器不知道你改了運(yùn)行時(shí)炸了才反應(yīng)過來的模式維護(hù)成本高得多。所以請先放下優(yōu)化運(yùn)行性能的執(zhí)念。這篇文章要聊的是as const如何讓類型系統(tǒng)更精確、讓代碼更安全、讓工程長期更好維護(hù)以及它在這種性能維度上的完整應(yīng)用和代價(jià)。明白這一點(diǎn)后面的一切才有意義。1.1 運(yùn)行時(shí)零開銷的驗(yàn)證看編譯產(chǎn)物要驗(yàn)證as const沒有運(yùn)行時(shí)開銷最簡單的方式是直接看編譯產(chǎn)物。// 源碼 const config { apiPrefix: /api/v1, timeout: 5000, } as const;用默認(rèn)配置編譯后你得到的是// 產(chǎn)物 const config { apiPrefix: /api/v1, timeout: 5000, };as const消失了。它從頭到尾都只活在類型空間從未進(jìn)入值空間。所以哪怕你在一個(gè)每秒調(diào)用上萬次的函數(shù)里寫as const也不會(huì)有一丁點(diǎn)運(yùn)行時(shí)影響。這一點(diǎn)和enum、普通const斷言有著本質(zhì)區(qū)別——后面兩者都會(huì)產(chǎn)出真實(shí)的對象或表達(dá)式而as const連影子都沒有。1.2 真正的性能在編譯期和開發(fā)期既然運(yùn)行時(shí)零開銷那它到底在優(yōu)化什么我用一個(gè)很常見的例子來說明。假設(shè)你要維護(hù)一個(gè)任務(wù)狀態(tài)表const TASK_STATUS { todo: todo, doing: doing, done: done, } as const;有了它之后你可以直接導(dǎo)出聯(lián)合類型type TaskStatus typeof TASK_STATUS[keyof typeof TASK_STATUS]; // 結(jié)果todo | doing | done沒有as const的時(shí)候typeof TASK_STATUS推導(dǎo)出來是{ todo: string; doing: string; done: string }取到的TaskStatus就是string。一旦你把TaskStatus當(dāng)成string用后面所有函數(shù)參數(shù)、返回值、對象屬性的類型檢查全部失去精確性。你要么手動(dòng)寫type TaskStatus todo | doing | done讓類型和值分離要么每次使用都做類型斷言。前者的問題是——你維護(hù)了兩份真相改值的時(shí)候忘了改類型編譯器不會(huì)提醒你直到運(yùn)行時(shí)某個(gè)分支判斷失效。后者的問題是——到處斷言代碼丑且不安全等于自己把類型系統(tǒng)的護(hù)甲脫了。as const直接把這兩條路都堵死值在哪里類型就在哪里。改TASK_STATUS的某個(gè)枚舉值所有相關(guān)的聯(lián)合類型自動(dòng)跟著變。你不再需要記得去同步類型因?yàn)轭愋透揪褪菑闹道锼愠鰜淼?。這部分節(jié)省的時(shí)間長期來看非?？捎^。1.3 一個(gè)簡單的性能賬本我自己在團(tuán)隊(duì)里推廣as const時(shí)喜歡算一筆賬一個(gè)常量表從 3 個(gè)值增加到 8 個(gè)值手寫聯(lián)合類型的方式需要同時(shí)改 2 個(gè)地方左右搖頭確認(rèn)兩邊一致用as const的方式只需要改 1 個(gè)地方聯(lián)合類型自動(dòng)擴(kuò)展編譯器在引用處幫你把關(guān)。假設(shè)每次兩邊同步平均花 10 分鐘一個(gè)月改 5 次一年就是 10 個(gè)小時(shí)。這還只是單一常量表。項(xiàng)目里有幾十個(gè)常量表呢類型錯(cuò)誤引發(fā)的線上事故呢這些成本算進(jìn)去as const帶來的性能收益其實(shí)高得驚人。只是這種收益不像運(yùn)行時(shí)性能那樣能用毫秒度量它體現(xiàn)在你不會(huì)犯的錯(cuò)和不用花的排查時(shí)間上。2. 類型推導(dǎo)規(guī)則拆解數(shù)組、對象和 const 的相互作用很多人用as const只是背了個(gè)結(jié)論給數(shù)組加這個(gè)數(shù)組就變成只讀了。但實(shí)際上它的推導(dǎo)行為背后有一條非常清晰的邏輯鏈TypeScript 只有在確定你不會(huì)改變某個(gè)值的時(shí)候才敢把它的類型收窄到字面量。理解這條邏輯鏈比記住結(jié)論重要得多。2.1 一段基礎(chǔ)代碼看 TS 怎么把可能變當(dāng)成了一定會(huì)變先看最基本的規(guī)則const userName zhang3; // userName 的類型是 zhang3字面量類型 let nickName zhang3; // nickName 的類型是 string同樣是賦值一個(gè)字符串const聲明的變量推導(dǎo)出字面量類型let聲明的變量卻拓寬為string。為什么因?yàn)閏onst保證了這個(gè)變量不會(huì)再被重新賦值那把類型寫成字面量是安全的。而let隨時(shí)可能被改成別的字符串TypeScript 只能老老實(shí)實(shí)給它string這種寬泛類型。這個(gè)規(guī)則遇到數(shù)組和對象會(huì)出問題。看這段const permissionList [read, write]; // 類型string[] const userConfig { name: admin, role: admin, }; // 類型{ name: string; role: string }注意這里的變量都是const但數(shù)組元素和對象屬性仍然被拓寬了。原因在于const只保證這個(gè)變量不能被重新賦值并不保證這個(gè)數(shù)組里的元素不能被修改或這個(gè)對象的屬性不能被修改。permissionList.push(execute); // 合法 userConfig.role guest; // 合法只要存在修改的可能性TypeScript 就不能把元素類型收窄成read | write因?yàn)橐坏┦照厦娴膬尚写a就會(huì)讓類型系統(tǒng)徹底失真。所以它對數(shù)組推導(dǎo)string[]對對象推導(dǎo)string屬性這是為了讓類型和運(yùn)行時(shí)保持一致。2.2 as const 的作用字面量固化加只讀鎖定現(xiàn)在再看as const做了什么const permissionList [read, write] as const; // 類型readonly [read, write]是一個(gè)只讀元組 const userConfig { name: admin, role: admin, } as const; // 類型{ readonly name: admin; readonly role: admin }它的本質(zhì)是一個(gè)類型斷言向 TypeScript 聲明兩件事不要再拓寬把所有值按照字面量類型理解全部只讀數(shù)組變成只讀元組對象屬性全部加上readonly。有了這兩條約束之后permissionList.push會(huì)報(bào)錯(cuò)userConfig.role guest也會(huì)報(bào)錯(cuò)。而正因?yàn)?TypeScript 知道你改不了它們了它才放心地把read | write這樣的字面量聯(lián)合類型用在后續(xù)的推導(dǎo)里。只讀是窄化的前提窄化是安全性的來源。對比一下元組和數(shù)組的區(qū)別沒有as const時(shí)[read, write]推導(dǎo)的是string[]長度和元素順序都是不固定的。加了as const后它變成一個(gè)固定長度、固定元素順序、每個(gè)元素都有自己獨(dú)立類型的元組。這意味著你可以放心地用元組[0]拿到read而不是string。這個(gè)特性在解析固定格式的配置、處理成對數(shù)據(jù)時(shí)非常好用。2.3 readonly 不是附帶產(chǎn)物而是約束成立的底牌我見過不少初學(xué)者問為什么as const非要順帶加readonly我只想要字面量類型不行嗎答案是不行至少在當(dāng)前的設(shè)計(jì)里不行。想理解這個(gè)關(guān)聯(lián)可以做一個(gè)思想實(shí)驗(yàn)const statusMap { todo: todo, done: done, } as const; let currentStatus statusMap.todo; // 類型 todo currentStatus statusMap.done; // 類型 done在上面的代碼里currentStatus的類型會(huì)根據(jù)賦值的不同而改變嗎不會(huì)。它一開始推斷為todo當(dāng)你嘗試賦值為statusMap.done時(shí)類型檢查器會(huì)發(fā)現(xiàn)done不能賦給todo于是報(bào)錯(cuò)。這在很多場景下并不是我們想要的。但如果去掉 readonly讓statusMap.todo可以被改成其他字符串呢那類型系統(tǒng)就更沒法保證statusMap.todo永遠(yuǎn)是todo了。基于它做的任何字面量聯(lián)合類型都不再安全。所以readonly不是可有可無的裝修它是在為字面量類型的安全性兜底。理解這一點(diǎn)之后你對as const的使用會(huì)自然多一層判斷我是否確定這個(gè)值在生命周期內(nèi)不會(huì)被修改如果是放心用如果否它就不適合加as const。3. 高頻實(shí)戰(zhàn)把 as const 用在常量表、事件映射和路由配置里理論講得再多不如看幾個(gè)真實(shí)項(xiàng)目里高頻出現(xiàn)的使用姿勢。這一節(jié)我總結(jié)了三個(gè)最常把a(bǔ)s const用在刀刃上的場景每一個(gè)都直接提升了代碼的可維護(hù)性和類型安全度。3.1 常量表 keyof typeof聯(lián)合類型自動(dòng)生成這是as const最基礎(chǔ)也最實(shí)用的用法。說一個(gè)我自己的使用習(xí)慣。我在項(xiàng)目里經(jīng)常需要定義各種狀態(tài)集合比如任務(wù)的pending / processing / done訂單的unpaid / paid / refunded用戶的active / disabled。最早的寫法是這樣的enum OrderStatus { Unpaid unpaid, Paid paid, Refunded refunded, }后來我發(fā)現(xiàn)enum有幾個(gè)問題。第一它有自己的運(yùn)行時(shí)對象形態(tài)即使只需要字符串編譯產(chǎn)物里也會(huì)多出一個(gè)鍵值映射對象第二在isolatedModules下使用const enum會(huì)有兼容性限制第三它的類型和值是綁定的但字符串和枚舉名之間的映射關(guān)系在代碼里不夠直觀。我現(xiàn)在的首選是as const常量表const ORDER_STATUS { UNPAID: unpaid, PAID: paid, REFUNDED: refunded, } as const; type OrderStatus typeof ORDER_STATUS[keyof typeof ORDER_STATUS]; // unpaid | paid | refunded這行keyof typeof的寫法值得仔細(xì)拆一下。typeof ORDER_STATUS拿到的是對象本身的類型也就是{ readonly UNPAID: unpaid; readonly PAID: paid; readonly REFUNDED: refunded }keyof拿到所有鍵的聯(lián)合UNPAID | PAID | REFUNDED再用索引訪問類型T[K]把每個(gè)鍵對應(yīng)的值取出來得到unpaid | paid | refunded。這套寫法的最大優(yōu)勢是單一數(shù)據(jù)源。哪天產(chǎn)品說要加一個(gè)CANCELLED狀態(tài)你只需要在常量表里加一行const ORDER_STATUS { UNPAID: unpaid, PAID: paid, REFUNDED: refunded, CANCELLED: cancelled, } as const;代碼里所有用到OrderStatus的地方會(huì)自動(dòng)多出一個(gè)合法值。函數(shù)參數(shù)、接口屬性、條件判斷全部聯(lián)動(dòng)。你不需要去搜索哪個(gè)文件里手寫了聯(lián)合類型因?yàn)楦静淮嬖诘诙菪枰降穆暶鳌?.2 事件映射用泛型推斷 payload替代 enum第二個(gè)高頻場景是事件映射。尤其是寫類似 Redux 的 reducer、事件總線、或是游戲引擎里的消息分發(fā)時(shí)as const加泛型可以幫你做一個(gè)非常安全的類型映射。先定義一個(gè)事件表const EVENTS { CLICK: { type: CLICK, payload: { x: number; y: number } }, KEYDOWN: { type: KEYDOWN, payload: { key: string } }, SCROLL: { type: SCROLL, payload: { deltaY: number } }, } as const; type EventMap typeof EVENTS; type EventType keyof EventMap; type EventName EventMap[EventType][type]; // CLICK | KEYDOWN | SCROLL注意因?yàn)閍s const的存在EventMap[EventType][type]能精確推導(dǎo)出CLICK | KEYDOWN | SCROLL。如果沒有as const這里得到的會(huì)是string整個(gè)事件系統(tǒng)就失去了核心約束力。然后可以寫一個(gè)泛型的emit函數(shù)function emitE extends EventName( type: E, payload: EventMap[ExtractEventType, { type: E }][payload] ) { // 分發(fā)邏輯 console.log(type, payload); } emit(CLICK, { x: 1, y: 2 }); // ok emit(CLICK, { key: a }); // 報(bào)錯(cuò)payload 類型不匹配 emit(HOVER, {}); // 報(bào)錯(cuò)不存在的事件名這個(gè)模式的威力在于事件名和 payload 的對應(yīng)關(guān)系完全由數(shù)據(jù)表驅(qū)動(dòng)。你不需要為每個(gè)事件單獨(dú)寫一個(gè)接口不需要在emit函數(shù)里做一串switch窄化。新增事件時(shí)只需要在EVENTS里加一項(xiàng)其他所有調(diào)用點(diǎn)的類型校驗(yàn)立刻生效。如果用enum加各種手動(dòng)接口的方式實(shí)現(xiàn)同樣功能光是維護(hù)事件名和 payload 的同步關(guān)系就夠頭疼的。這也是我在中大型前端項(xiàng)目里力推as const的重要原因。3.3 路由與權(quán)限配置字面量類型把入口參數(shù)鎖死第三個(gè)場景是路由表和權(quán)限表。現(xiàn)在很多前端項(xiàng)目的路由是集中配置的比如這樣的const ROUTES { HOME: /, PROFILE: /profile, SETTINGS: /settings, ADMIN: /admin, } as const; type RoutePath typeof ROUTES[keyof typeof ROUTES]; // / | /profile | /settings | /admin有了RoutePath之后你的navigate函數(shù)可以寫成這樣function navigate(path: RoutePath) { // 跳轉(zhuǎn)邏輯 } navigate(/settings); // ok navigate(/setting); // 報(bào)錯(cuò)拼錯(cuò)了路徑編譯器能攔住 navigate(/profile?id1); // 報(bào)錯(cuò)這個(gè)字符串不是 RoutePath 的成員不要小看這種約束。在一個(gè)有幾十條路由的項(xiàng)目里字符串拼錯(cuò)是家常便飯。如果navigate的參數(shù)是string那這類錯(cuò)誤只能等運(yùn)行時(shí)頁面白屏才能發(fā)現(xiàn)。用它當(dāng)參數(shù)類型之后編譯期就是你的測試員。權(quán)限配置也是同理const ROLES { USER: user, EDITOR: editor, ADMIN: admin, } as const; type Role typeof ROLES[keyof typeof ROLES]; function checkPermission(currentRole: Role, requiredRole: Role) { const roleRank: RecordRole, number { user: 1, editor: 2, admin: 3, }; return roleRank[currentRole] roleRank[requiredRole]; }注意這里RecordRole, number要求你為每一個(gè)角色都提供權(quán)重。如果以后加了個(gè)SUPER_ADMIN但忘了在roleRank里配置TypeScript 會(huì)直接報(bào)錯(cuò)。這種漏寫就報(bào)錯(cuò)的體驗(yàn)是手寫復(fù)雜類型時(shí)要花很多功夫才能達(dá)到的但as const天然就給了你。4. 進(jìn)階組合as const 與 satisfies、模板字面量和遞歸只讀as const單獨(dú)用已經(jīng)很強(qiáng)了但真正讓它發(fā)揮全部價(jià)值的是和其他類型特性聯(lián)動(dòng)。這一節(jié)是整篇文章含金量比較高的部分我把三個(gè)最常用的組合姿勢完整拆解。4.1 as const satisfies結(jié)構(gòu)校驗(yàn)和字面量一步到位satisfies是 TypeScript 4.9 引入的操作符它和as const是天生一對。它解決的是一個(gè)很微妙的矛盾你既要讓 TS 校驗(yàn)常量是否符合某個(gè)接口又不想讓校驗(yàn)過程把字面量類型拓寬成寬泛類型。看下面這個(gè)例子。項(xiàng)目里有一個(gè)國際化文案配置const COPY { title: 你好, description: 歡迎使用, buttonText: 確認(rèn), };你想確保這個(gè)配置滿足接口Recordstring, string于是這樣寫const COPY: Recordstring, string { title: 你好, description: 歡迎使用, buttonText: 確認(rèn), };類型檢查通過了但壞消息是COPY.title現(xiàn)在的類型是string而不是字面量你好。你失去了精確推導(dǎo)。那反過來用as constconst COPY { title: 你好, description: 歡迎使用, buttonText: 確認(rèn), } as const;字面量保住了但結(jié)構(gòu)校驗(yàn)沒有了。如果你在配置里寫錯(cuò)了一個(gè)字段名或者漏了某個(gè)必填項(xiàng)TS 不會(huì)提醒你。satisfies完美解決了這個(gè)兩難const COPY { title: 你好, description: 歡迎使用, buttonText: 確認(rèn), extra: 123, // 報(bào)錯(cuò)number 不能賦給 string } as const satisfies Recordstring, string; type CopyKeys keyof typeof COPY; // title | description | buttonText這段代碼做到了三件事COPY的結(jié)構(gòu)滿足接口要求屬性值保留精確的字面量類型任何不符合接口的項(xiàng)被直接攔下。一個(gè)關(guān)鍵字同時(shí)解決校驗(yàn)和窄化兩個(gè)需求。更具體的場景是配置文件的規(guī)范校驗(yàn)。比如某個(gè)第三方庫的選項(xiàng)對象interface LoggerOptions { level: debug | info | warn | error; prefix?: string; } const options { level: debug, prefix: [main], } as const satisfies LoggerOptions; // options.level 的類型是 debug而不是 debug | info | warn | error注意區(qū)別如果直接用const options: LoggerOptions { ... }options.level的類型會(huì)被拓寬成四個(gè)字的聯(lián)合你用它的地方就不能精準(zhǔn)處理。用了as const satisfies之后結(jié)構(gòu)校驗(yàn)沒丟字面量也保住了。4.2 模板字面量類型從常量表自動(dòng)拼出事件名模板字面量類型和as const的組合能在保持?jǐn)?shù)據(jù)源唯一的前提下自動(dòng)生成更龐大的聯(lián)合類型。舉個(gè)例子。項(xiàng)目里有一組 API 事件命名規(guī)則是資源名加動(dòng)作名比如user:created、order:paid、order:refunded。最自然的做法是定義一組前綴常量const RESOURCES { user: user, order: order, payment: payment, } as const; const ACTIONS { created: created, updated: updated, deleted: deleted, paid: paid, refunded: refunded, } as const;然后這樣生成完整事件名type Resource keyof typeof RESOURCES; type Action keyof typeof ACTIONS; type DomainEvent ${Resource}:${Action}; // user:created | user:updated | user:deleted | user:paid | ...你沒看錯(cuò)TypeScript 會(huì)自動(dòng)枚舉所有Resource和Action的組合生成的聯(lián)合類型多達(dá) 12 項(xiàng)而且每一個(gè)都是合法字面量。這比手寫 12 個(gè)字符串方便得多也比寫一套泛型工具函數(shù)直觀得多。更重要的是這個(gè)聯(lián)合類型完全由RESOURCES和ACTIONS兩個(gè)常量表驅(qū)動(dòng)。當(dāng)RESOURCES里新增一個(gè)admin資源時(shí)DomainEvent自動(dòng)多出admin:created、admin:updated等 5 個(gè)新值。你不需要記得去更新哪個(gè)類型定義因?yàn)樗緛砭蜎]有一個(gè)需要更新的定義。類似的用法還能生成 CSS 類名前綴、權(quán)限組合、路由前綴等。只要命名規(guī)則是固定前綴 固定后綴的組合式模板字符串加as const基本是最優(yōu)雅的解法。4.3 DeepReadonly 要不要寫分情況討論as const只保證一層只讀。這句話很多人知道但知道一層只讀意味著什么的人不多。const nested { user: { name: admin, permissions: [read, write], }, } as const; // nested.user.name 的類型是 admin很好 // nested.user.permissions 的類型是 readonly [read, write]也很好 // nested.user.permissions.push(execute) 會(huì)報(bào)錯(cuò)看起來一切正常。但如果嵌套層數(shù)再深一點(diǎn)呢const config { server: { host: 127.0.0.1, featureFlags: { darkMode: true, beta: false, }, }, } as const;featureFlags的上一層被as const約束了所以config.server是只讀的config.server.featureFlags也是只讀的。這只讀是遞歸傳染的嗎是也不是。準(zhǔn)確地說as const是遞歸作用到對象樹的每一層的。上面的featureFlags內(nèi)部屬性darkMode也確實(shí)被推導(dǎo)成true而不是boolean。所以對普通對象來說完全嵌套的字面量推導(dǎo)是生效的。真正的問題出在數(shù)組上?？催@個(gè)const matrix [[1, 2], [3, 4]] as const; // 類型readonly [readonly [1, 2], readonly [3, 4]] const mutating [[1, 2], [3, 4]] as const; mutating[0].push(5); // 這樣會(huì)報(bào)錯(cuò)嗎讓我算一下。mutating的類型是readonly [readonly [1, 2], readonly [3, 4]]。mutating[0]的類型是readonly [1, 2]它是只讀元組push方法確實(shí)不存在所以會(huì)報(bào)錯(cuò)。對數(shù)組嵌套as const的遞歸推導(dǎo)也是可靠的。那我為什么還要提醒只淺層因?yàn)橐坏┠阌昧似渌愋筒僮鞣@個(gè)遞歸可能被截?cái)唷１热缬昧藄atisfies配合接口類型時(shí)對象會(huì)先經(jīng)歷接口兼容性檢查而接口里的數(shù)組類型如果不是元組就可能被拓寬。還有一個(gè)更隱蔽的場景as const不能阻止對象被整體賦值給可變類型后再修改。const original { value: 1 } as const; // 這里的 target 是可變的 let mutableTarget: { value: number } original; mutableTarget.value 999; // 合法original 沒變但類型被繞過所以如果你真的需要一個(gè) DeepReadonly 類型來配合復(fù)雜嵌套結(jié)構(gòu)自己寫一個(gè)也不難type DeepReadonlyT { readonly [K in keyof T]: T[K] extends object ? T[K] extends readonly unknown[] ? DeepReadonlyT[K] : DeepReadonlyT[K] : T[K]; }; type ReadonlyConfig DeepReadonlytypeof config;但我個(gè)人的建議是不要默認(rèn)給所有東西套 DeepReadonly。絕大多數(shù)業(yè)務(wù)場景下as const自帶的一層只讀已經(jīng)足夠攔截 95% 的誤修改。DeepReadonly 是給底層庫、框架級代碼、領(lǐng)域模型聲明用的重武器用得越多類型計(jì)算越復(fù)雜編譯期負(fù)擔(dān)也隨之上升。工具要用在刀刃上。5. 邊界與陷阱as const 什么時(shí)候會(huì)坑你沒有任何技巧是銀彈as const也一樣。它有三個(gè)比較經(jīng)典的坑以及一些更容易被忽視的邊界我踩過、也看過別人踩過值得拿出來專門講。5.1 解構(gòu)與回調(diào)參數(shù)字面量類型說沒就沒第一個(gè)坑是解構(gòu)和函數(shù)參數(shù)會(huì)丟失部分類型信息。先看解構(gòu)const STATUS { TODO: todo, DONE: done, } as const; // 錯(cuò)誤示范函數(shù)參數(shù)用了 const 斷言對象但斷言的類型會(huì)丟失嗎 function processStatus(status: typeof STATUS[keyof typeof STATUS]) {} // 直接傳值是安全的 processStatus(STATUS.TODO); // ok // 但解構(gòu)出來就可能出問題 const { TODO, DONE } STATUS; processStatus(DONE); // 這里類型是什么實(shí)際上因?yàn)榻鈽?gòu)出來的DONE是用const聲明的TypeScript 會(huì)保留done這個(gè)字面量類型。所以直接這樣用沒問題。真正的坑在數(shù)組解構(gòu)和函數(shù)默認(rèn)值上。看這個(gè)例子const COLORS [red, green, blue] as const; function pickColor(color: typeof COLORS[number]) { // ... } // 解構(gòu)數(shù)組元素 const [firstColor, secondColor] COLORS; pickColor(firstColor); // 類型是 redok數(shù)組解構(gòu)配合const聲明索引元素保持字面量這也還能用。真正的問題出在把元素賦給let變量或者放進(jìn)可變?nèi)萜骼?。let currentColor COLORS[1]; // 類型變成 green | undefined不是 green currentColor COLORS[2]; // 此時(shí)類型拓寬為 blue其實(shí)這里let聲明只是導(dǎo)致后續(xù)可以重新賦值而賦的值也會(huì)被收窄到聯(lián)合成員。真正讓新手困惑的坑是當(dāng)as const的只讀元組被展開到可變上下文時(shí)元組退化為數(shù)組。function splitColors(colors: readonly string[]) { const copy: string[] [...colors]; // ok copy.push(yellow); // ok }我自己在實(shí)戰(zhàn)中遇到最多的問題反而是在useState這類泛型 Hook 里。useState返回的數(shù)組是可變的[state, setState]如果你把一個(gè)as const的元組塞進(jìn)去希望它保持元組類型結(jié)果往往會(huì)變成普通數(shù)組類型const [state, setState] useState([1, 2] as const); // state 的類型推斷不是 readonly [1, 2]而是 number[]這是因?yàn)閡seState的泛型參數(shù)期望的是一個(gè)普通State它的默認(rèn)推斷邏輯會(huì)優(yōu)先用可寫數(shù)組。要保住元組形態(tài)就得顯式給泛型const [state, setState] useStatereadonly [1, 2]([1, 2] as const);這種場景不多但一旦遇到而你不理解原理排查起來很容易繞遠(yuǎn)路。5.2 includes 的嚴(yán)格參數(shù)攔截錯(cuò)別字也攔截了合法輸入第二個(gè)坑更隱蔽。當(dāng)你對as const數(shù)組調(diào)用includes時(shí)參數(shù)類型會(huì)被收窄成聯(lián)合成員。const ALLOWED_TAGS [javascript, typescript, css] as const; function isAllowed(tag: string) { return ALLOWED_TAGS.includes(tag); // 報(bào)錯(cuò)類型 string 的參數(shù)不能賦給類型 javascript | typescript | css 的參數(shù) }這乍看之下很反直覺明明includes應(yīng)該是檢查這個(gè)字符串在不在數(shù)組里怎么反而不讓我檢查任意字符串了原因在于Array.prototype.includes的參數(shù)類型實(shí)際上是searchElement: TT是數(shù)組元素類型。當(dāng)數(shù)組變成readonly [javascript, typescript, css]時(shí)T就是這個(gè)字面量聯(lián)合。TS 認(rèn)為你要查找的值必須來自這個(gè)聯(lián)合如果你傳入一個(gè)不屬于聯(lián)合的string它覺得你根本沒可能找到肯定是寫錯(cuò)了。問題是實(shí)際場景里我們可能真的需要用外部輸入來判斷。比如用戶從表單里輸入一個(gè)標(biāo)簽我們要檢查它是否合法。這時(shí)候includes反而會(huì)擋住你。業(yè)內(nèi)常用的解決方案有幾個(gè)我推薦第一個(gè)// 方案一把檢查目標(biāo)斷言為聯(lián)合類型 function isAllowed(tag: string) { return (ALLOWED_TAGS as readonly string[]).includes(tag); } // 方案二用 Set 代替數(shù)組 const allowedTagSet new Setstring(ALLOWED_TAGS); function isAllowed(tag: string) { return allowedTagSet.has(tag); } // 方案三手動(dòng)寫一個(gè)類型守衛(wèi) function isAllowed(tag: string): tag is typeof ALLOWED_TAGS[number] { return (ALLOWED_TAGS as readonly string[]).includes(tag); }方案三是我最推薦的因?yàn)樗粌H解決了檢查問題還讓調(diào)用方的 TypeScript 知道一旦isAllowed返回true后續(xù)代碼里的tag就自動(dòng)收窄為合法標(biāo)簽聯(lián)合類型。這種守衛(wèi) 收窄的組合是as const類型體系里很好用的一環(huán)。5.3 淺層只讀的誤導(dǎo)嵌套對象改起來沒人攔前面我講過as const對嵌套對象是遞歸的但依然有個(gè)容易誤解的地方只讀約束是類型層面的不是運(yùn)行時(shí)層面的?？催@段代碼const nestedConfig { database: { host: localhost, port: 5432, }, } as const; // TypeScript 層面下面這行會(huì)報(bào)錯(cuò) // nestedConfig.database.port 5433; // 報(bào)錯(cuò)不能分配到只讀屬性TS 會(huì)攔這沒問題。但如果有人用類型斷言繞過檢查const mutableConfig nestedConfig as { database: { host: string; port: number }; }; mutableConfig.database.port 9999; // 運(yùn)行時(shí)不報(bào)錯(cuò)這一行運(yùn)行時(shí)完全正常nestedConfig.database.port在運(yùn)行時(shí)變成了 9999。雖然類型系統(tǒng)里它依然是5432但實(shí)際值已經(jīng)變了。這就是類型層面的只讀不等于運(yùn)行時(shí)凍結(jié)。很多初學(xué)者誤以為as const的效果等同于Object.freeze這是完全錯(cuò)誤的。Object.freeze是運(yùn)行時(shí)特性會(huì)真正阻止屬性寫入而as const只是類型層面的標(biāo)記編譯后消失。如果你的數(shù)據(jù)要和不可靠的第三方庫交互或者會(huì)被序列化后經(jīng)過某些會(huì)修改對象的中間層那as const的只讀保護(hù)其實(shí)是很脆弱的。那它還有用嗎當(dāng)然有。它的意義在于在你自己的代碼范圍內(nèi)TypeScript 能提前發(fā)現(xiàn)修改意圖幫你養(yǎng)成不修改常量的習(xí)慣。至于運(yùn)行時(shí)層面的不可變性如果需要請用Object.freeze但別指望類型層面的約束能防住所有運(yùn)行時(shí)篡改。5.4 真的要可變配置時(shí)別硬上 as const最后一個(gè)邊界是使用場景的判斷。as const很好但不代表所有常量都應(yīng)該加它。如果你的配置確實(shí)需要在運(yùn)行時(shí)被修改比如一個(gè)熱更新的標(biāo)志位、一個(gè)動(dòng)態(tài)變化的主題配置、一個(gè)由后端返回后還要加工的數(shù)據(jù)那加as const只會(huì)讓你到處寫類型斷言去繞過只讀約束反而把代碼弄得很難看。// 這種就不適合加 as const let dynamicConfig { features: [darkMode], retryCount: 3, };一個(gè)實(shí)用的判斷標(biāo)準(zhǔn)是問自己這個(gè)值在定義之后我是否希望它永遠(yuǎn)不變?nèi)绻鸢甘鞘羌觓s const如果答案是它其實(shí)會(huì)變只是目前沒變那別加老老實(shí)實(shí)寫一個(gè)顯式類型接口讓可變的語義在類型里清晰表達(dá)出來。我在維護(hù)的某個(gè)老項(xiàng)目里見過一個(gè)反面案例團(tuán)隊(duì)為了追求高級技巧把應(yīng)用配置全部加了as const結(jié)果每次動(dòng)態(tài)更新開關(guān)都要改成let并重新斷言代碼里塞滿了as、ts-ignore和嵌套的解構(gòu)拷貝。類型安全沒有提升反而因?yàn)榧s束過強(qiáng)導(dǎo)致所有人都在繞路。工具是為人服務(wù)的不是為炫技服務(wù)的。6. 關(guān)于編譯性能的實(shí)測與體會(huì)as const 會(huì)拖慢 tsc 嗎既然標(biāo)題里有性能完全總結(jié)那編譯性能這個(gè)話題繞不開。很多團(tuán)隊(duì)在選擇是否使用as const時(shí)會(huì)擔(dān)心這種類型斷言會(huì)不會(huì)讓 tsc 和 IDE 變慢我用實(shí)際經(jīng)驗(yàn)說說結(jié)論。6.1 類型檢查器如何看待字面量類型先給一個(gè)明確的結(jié)論普通使用as const基本不會(huì)對編譯性能產(chǎn)生可感知的影響。原因是as const產(chǎn)生的字面量類型和只讀元組在類型檢查器內(nèi)部是相對簡單的結(jié)構(gòu)。它就相當(dāng)于告訴編譯器這里是一個(gè)固定值。檢查一個(gè)賦值是否符合todo | done比檢查一個(gè)復(fù)雜泛型參數(shù)推導(dǎo)要快得多。類型檢查的性能瓶頸從來不在字面量數(shù)量多上而在類型計(jì)算復(fù)雜度高上。真正拖慢編譯的是泛型遞歸、模板字面量類型的大規(guī)模組合、超大的聯(lián)合類型、交叉類型的一層層化簡。這些恰恰是satisfies、DeepReadonly、模板字面量類型這些進(jìn)階組合可能引入的。所以如果你感覺項(xiàng)目加了as const后編譯變慢了更可能的原因是你在同一個(gè)文件里同時(shí)用了大量高級類型工具而不是as const本身。6.2 用 extendedDiagnostics 量化如果你確實(shí)想量化TypeScript 官方提供了編譯診斷工具npx tsc --extendedDiagnostics跑完之后會(huì)輸出一份檢查時(shí)間報(bào)告其中這幾項(xiàng)值得關(guān)注Files: 245 Types: 1820 Instantiations: 3210 Memory used: 54210 kB I/O read time: 0.42s Parse time: 2.13s Bind time: 0.68s Check time: 5.12s Emit time: 1.08s Total time: 9.43sTypes是類型實(shí)例的總數(shù)Instantiations是泛型實(shí)例化的次數(shù)這一項(xiàng)最能反映類型計(jì)算的負(fù)擔(dān)Check time是類型檢查的總時(shí)長。你可以挑兩個(gè)文件一個(gè)用as const函數(shù)一個(gè)不用分別測Check time的變化。我實(shí)測的經(jīng)驗(yàn)是在同一個(gè)項(xiàng)目里增刪幾十處as constCheck time的變化通常不超過 0.1 秒。而如果你加了十幾個(gè)模板字符串類型的深層遞歸Instantiations可能會(huì)翻好幾倍。6.3 真正拖慢編譯的是哪些東西我把這幾年遇到過的編譯變慢的元兇排了個(gè)序前幾名幾乎沒有一個(gè)是as const本身造成的深度遞歸的映射類型比如DeepReadonly在大型接口上無限遞歸編譯期要反復(fù)展開模板字面量類型的笛卡爾積${A}${B}這種寫法會(huì)生成龐大聯(lián)合如果 A 有 20 個(gè)成員、B 有 30 個(gè)成員瞬間就有 600 種組合需要檢查巨型聯(lián)合類型超過幾百個(gè)成員的聯(lián)合在每次 assignability 檢查時(shí)都要逐一比對泛型函數(shù)調(diào)用鏈一層層泛型推斷每一步都要做復(fù)雜的上下文派生。有意思的是第 2 條和第 3 條經(jīng)常和as const一起出現(xiàn)。比如我用as const生成了 600 個(gè)合法字符串的聯(lián)合類型然后在emit函數(shù)里做分發(fā)這是進(jìn)階玩法也會(huì)帶來類型檢查開銷。但這是進(jìn)階玩法的代價(jià)不是as const的代價(jià)。我的建議是保持as const在常量表和普通對象上的日常使用放心大膽用但如果你需要寫那種遞歸映射類型或模板字面量大型組合要有意識(shí)地控制規(guī)模并做好性能觀測。6.4 組織好你的類型才是最大的性能優(yōu)化最后我想說一個(gè)容易被忽略的點(diǎn)真正的編譯性能優(yōu)化不取決于用不用as const而取決于你如何組織類型。as const的價(jià)值恰恰是讓值成為類型的來源減少手寫重復(fù)類型。項(xiàng)目里手寫的重復(fù)類型越少類型系統(tǒng)需要處理的冗余結(jié)構(gòu)就越少編譯檢查的負(fù)載自然越低。從這個(gè)角度看合理使用as const不僅不是編譯性能的負(fù)擔(dān)反而是間接幫助編譯器減輕工作量的手段。我也遇到過另一個(gè)極端一個(gè)團(tuán)隊(duì)為了統(tǒng)一管理類型把幾十個(gè)常量表里的幾百個(gè)常量全部塞進(jìn)一個(gè)types.ts的as const巨對象里然后用一堆Extract和模板字面量去拆分成各種類型。結(jié)果每次改動(dòng)這個(gè)文件幾乎所有依賴它的文件都要重新做一輪類型檢查編譯時(shí)間肉眼可見地上升。這就屬于把類型源頭變成類型瓶頸的錯(cuò)誤組織方式。正確的做法是把常量表按業(yè)務(wù)域拆開每個(gè)域單獨(dú)一個(gè)文件用as const保持單源再用satisfies做結(jié)構(gòu)校驗(yàn)。這樣每次改動(dòng)只影響相關(guān)業(yè)務(wù)域的類型檢查范圍編譯時(shí)間保持穩(wěn)定代碼的模塊邊界也更清晰。最后再分享一個(gè)我個(gè)人的實(shí)戰(zhàn)習(xí)慣。我在團(tuán)隊(duì)里推行as const時(shí)不會(huì)一上來就要求所有人把所有常量都改造成這種寫法。我會(huì)先挑一個(gè)高頻使用的狀態(tài)常量表做范例把typeof STATUS[keyof typeof STATUS]這種索引類型寫清楚讓大家看到改一處、全局聯(lián)動(dòng)的效果。大部分人用過一次之后就會(huì)自發(fā)地在其他地方應(yīng)用起來因?yàn)檫@種值即類型的體驗(yàn)確實(shí)舒服。另外如果你已經(jīng)開始用as const請務(wù)必記住配套的satisfies和keyof typeof這三件套。它們不是花哨的語法糖而是讓常量表同時(shí)具備結(jié)構(gòu)校驗(yàn)字面量精確和聯(lián)合類型自動(dòng)生成三種能力的完整方案。用熟了之后你會(huì)發(fā)現(xiàn)很多曾經(jīng)需要手寫泛型工具類型的場景其實(shí)用這三個(gè)基礎(chǔ)特性組合一下就足夠了。 TypeScript as const 完全解析：類型推導(dǎo)、性能真相與工程實(shí)踐
1. 先說清一個(gè)誤區(qū)as const 優(yōu)化的到底是誰的性能我見過不少剛接觸 TypeScript 的同學(xué)一看到as const 性能總結(jié)這種標(biāo)題第一反應(yīng)是是不是給代碼提速用的是不是運(yùn)行的時(shí)候能省點(diǎn)內(nèi)存、少點(diǎn)計(jì)算其實(shí)完全不是。as const是純編譯期的類型標(biāo)記它不會(huì)生成任何一行運(yùn)行時(shí)代碼。你在源碼里寫const obj { name: admin } as const編譯產(chǎn)物依然是const obj { name: admin }字面量、括號(hào)、分號(hào)一樣都不會(huì)多。運(yùn)行時(shí)該多快還多快該占多少內(nèi)存還占多少內(nèi)存。這里沒有任何黑魔法也沒有任何性能優(yōu)化。那標(biāo)題里的性能究竟指什么我自己的理解是它優(yōu)化的是一種更高維度的性能——類型系統(tǒng)的工作性能和開發(fā)者的使用性能。展開說有三層第一層是類型推導(dǎo)的準(zhǔn)確率。沒有as const的時(shí)候TypeScript 面對一個(gè)對象或數(shù)組為了照顧你可能會(huì)改它這種可能性會(huì)把屬性拓寬成string、number這種寬泛類型。一旦你在后續(xù)代碼里需要精確到某個(gè)字面量值類型檢查器就得靠你手動(dòng)寫類型斷言去補(bǔ)充信息或者靠各種繞來繞去的判斷去猜。這個(gè)過程既費(fèi)腦也費(fèi)編譯期的推理時(shí)間。as const直接把最精確的類型告訴檢查器后面所有檢查都基于一個(gè)已知答案展開推理成本反而低。第二層是開發(fā)者的時(shí)間性能。最直觀的表現(xiàn)是你少寫一大堆重復(fù)的類型聲明。比如明明有個(gè)狀態(tài)常量表你卻要在旁邊再維護(hù)一份聯(lián)合類型改一處漏一處是家常便飯。as const讓值和類型同源改一處全局生效開發(fā)效率完全是另一回事。第三層是長期的維護(hù)性能。項(xiàng)目規(guī)模上去以后最大的開銷其實(shí)是改一個(gè)常量要找遍所有引用。用as const把常量表做成類型源頭改配置即改類型TS 編譯器會(huì)替你把所有不匹配的調(diào)用點(diǎn)揪出來。對比起來手寫聯(lián)合類型那種編譯器不知道你改了運(yùn)行時(shí)炸了才反應(yīng)過來的模式維護(hù)成本高得多。所以請先放下優(yōu)化運(yùn)行性能的執(zhí)念。這篇文章要聊的是as const如何讓類型系統(tǒng)更精確、讓代碼更安全、讓工程長期更好維護(hù)以及它在這種性能維度上的完整應(yīng)用和代價(jià)。明白這一點(diǎn)后面的一切才有意義。1.1 運(yùn)行時(shí)零開銷的驗(yàn)證看編譯產(chǎn)物要驗(yàn)證as const沒有運(yùn)行時(shí)開銷最簡單的方式是直接看編譯產(chǎn)物。// 源碼 const config { apiPrefix: /api/v1, timeout: 5000, } as const;用默認(rèn)配置編譯后你得到的是// 產(chǎn)物 const config { apiPrefix: /api/v1, timeout: 5000, };as const消失了。它從頭到尾都只活在類型空間從未進(jìn)入值空間。所以哪怕你在一個(gè)每秒調(diào)用上萬次的函數(shù)里寫as const也不會(huì)有一丁點(diǎn)運(yùn)行時(shí)影響。這一點(diǎn)和enum、普通const斷言有著本質(zhì)區(qū)別——后面兩者都會(huì)產(chǎn)出真實(shí)的對象或表達(dá)式而as const連影子都沒有。1.2 真正的性能在編譯期和開發(fā)期既然運(yùn)行時(shí)零開銷那它到底在優(yōu)化什么我用一個(gè)很常見的例子來說明。假設(shè)你要維護(hù)一個(gè)任務(wù)狀態(tài)表const TASK_STATUS { todo: todo, doing: doing, done: done, } as const;有了它之后你可以直接導(dǎo)出聯(lián)合類型type TaskStatus typeof TASK_STATUS[keyof typeof TASK_STATUS]; // 結(jié)果todo | doing | done沒有as const的時(shí)候typeof TASK_STATUS推導(dǎo)出來是{ todo: string; doing: string; done: string }取到的TaskStatus就是string。一旦你把TaskStatus當(dāng)成string用后面所有函數(shù)參數(shù)、返回值、對象屬性的類型檢查全部失去精確性。你要么手動(dòng)寫type TaskStatus todo | doing | done讓類型和值分離要么每次使用都做類型斷言。前者的問題是——你維護(hù)了兩份真相改值的時(shí)候忘了改類型編譯器不會(huì)提醒你直到運(yùn)行時(shí)某個(gè)分支判斷失效。后者的問題是——到處斷言代碼丑且不安全等于自己把類型系統(tǒng)的護(hù)甲脫了。as const直接把這兩條路都堵死值在哪里類型就在哪里。改TASK_STATUS的某個(gè)枚舉值所有相關(guān)的聯(lián)合類型自動(dòng)跟著變。你不再需要記得去同步類型因?yàn)轭愋透揪褪菑闹道锼愠鰜淼?。這部分節(jié)省的時(shí)間長期來看非?？捎^。1.3 一個(gè)簡單的性能賬本我自己在團(tuán)隊(duì)里推廣as const時(shí)喜歡算一筆賬一個(gè)常量表從 3 個(gè)值增加到 8 個(gè)值手寫聯(lián)合類型的方式需要同時(shí)改 2 個(gè)地方左右搖頭確認(rèn)兩邊一致用as const的方式只需要改 1 個(gè)地方聯(lián)合類型自動(dòng)擴(kuò)展編譯器在引用處幫你把關(guān)。假設(shè)每次兩邊同步平均花 10 分鐘一個(gè)月改 5 次一年就是 10 個(gè)小時(shí)。這還只是單一常量表。項(xiàng)目里有幾十個(gè)常量表呢類型錯(cuò)誤引發(fā)的線上事故呢這些成本算進(jìn)去as const帶來的性能收益其實(shí)高得驚人。只是這種收益不像運(yùn)行時(shí)性能那樣能用毫秒度量它體現(xiàn)在你不會(huì)犯的錯(cuò)和不用花的排查時(shí)間上。2. 類型推導(dǎo)規(guī)則拆解數(shù)組、對象和 const 的相互作用很多人用as const只是背了個(gè)結(jié)論給數(shù)組加這個(gè)數(shù)組就變成只讀了。但實(shí)際上它的推導(dǎo)行為背后有一條非常清晰的邏輯鏈TypeScript 只有在確定你不會(huì)改變某個(gè)值的時(shí)候才敢把它的類型收窄到字面量。理解這條邏輯鏈比記住結(jié)論重要得多。2.1 一段基礎(chǔ)代碼看 TS 怎么把可能變當(dāng)成了一定會(huì)變先看最基本的規(guī)則const userName zhang3; // userName 的類型是 zhang3字面量類型 let nickName zhang3; // nickName 的類型是 string同樣是賦值一個(gè)字符串const聲明的變量推導(dǎo)出字面量類型let聲明的變量卻拓寬為string。為什么因?yàn)閏onst保證了這個(gè)變量不會(huì)再被重新賦值那把類型寫成字面量是安全的。而let隨時(shí)可能被改成別的字符串TypeScript 只能老老實(shí)實(shí)給它string這種寬泛類型。這個(gè)規(guī)則遇到數(shù)組和對象會(huì)出問題。看這段const permissionList [read, write]; // 類型string[] const userConfig { name: admin, role: admin, }; // 類型{ name: string; role: string }注意這里的變量都是const但數(shù)組元素和對象屬性仍然被拓寬了。原因在于const只保證這個(gè)變量不能被重新賦值并不保證這個(gè)數(shù)組里的元素不能被修改或這個(gè)對象的屬性不能被修改。permissionList.push(execute); // 合法 userConfig.role guest; // 合法只要存在修改的可能性TypeScript 就不能把元素類型收窄成read | write因?yàn)橐坏┦照厦娴膬尚写a就會(huì)讓類型系統(tǒng)徹底失真。所以它對數(shù)組推導(dǎo)string[]對對象推導(dǎo)string屬性這是為了讓類型和運(yùn)行時(shí)保持一致。2.2 as const 的作用字面量固化加只讀鎖定現(xiàn)在再看as const做了什么const permissionList [read, write] as const; // 類型readonly [read, write]是一個(gè)只讀元組 const userConfig { name: admin, role: admin, } as const; // 類型{ readonly name: admin; readonly role: admin }它的本質(zhì)是一個(gè)類型斷言向 TypeScript 聲明兩件事不要再拓寬把所有值按照字面量類型理解全部只讀數(shù)組變成只讀元組對象屬性全部加上readonly。有了這兩條約束之后permissionList.push會(huì)報(bào)錯(cuò)userConfig.role guest也會(huì)報(bào)錯(cuò)。而正因?yàn)?TypeScript 知道你改不了它們了它才放心地把read | write這樣的字面量聯(lián)合類型用在后續(xù)的推導(dǎo)里。只讀是窄化的前提窄化是安全性的來源。對比一下元組和數(shù)組的區(qū)別沒有as const時(shí)[read, write]推導(dǎo)的是string[]長度和元素順序都是不固定的。加了as const后它變成一個(gè)固定長度、固定元素順序、每個(gè)元素都有自己獨(dú)立類型的元組。這意味著你可以放心地用元組[0]拿到read而不是string。這個(gè)特性在解析固定格式的配置、處理成對數(shù)據(jù)時(shí)非常好用。2.3 readonly 不是附帶產(chǎn)物而是約束成立的底牌我見過不少初學(xué)者問為什么as const非要順帶加readonly我只想要字面量類型不行嗎答案是不行至少在當(dāng)前的設(shè)計(jì)里不行。想理解這個(gè)關(guān)聯(lián)可以做一個(gè)思想實(shí)驗(yàn)const statusMap { todo: todo, done: done, } as const; let currentStatus statusMap.todo; // 類型 todo currentStatus statusMap.done; // 類型 done在上面的代碼里currentStatus的類型會(huì)根據(jù)賦值的不同而改變嗎不會(huì)。它一開始推斷為todo當(dāng)你嘗試賦值為statusMap.done時(shí)類型檢查器會(huì)發(fā)現(xiàn)done不能賦給todo于是報(bào)錯(cuò)。這在很多場景下并不是我們想要的。但如果去掉 readonly讓statusMap.todo可以被改成其他字符串呢那類型系統(tǒng)就更沒法保證statusMap.todo永遠(yuǎn)是todo了。基于它做的任何字面量聯(lián)合類型都不再安全。所以readonly不是可有可無的裝修它是在為字面量類型的安全性兜底。理解這一點(diǎn)之后你對as const的使用會(huì)自然多一層判斷我是否確定這個(gè)值在生命周期內(nèi)不會(huì)被修改如果是放心用如果否它就不適合加as const。3. 高頻實(shí)戰(zhàn)把 as const 用在常量表、事件映射和路由配置里理論講得再多不如看幾個(gè)真實(shí)項(xiàng)目里高頻出現(xiàn)的使用姿勢。這一節(jié)我總結(jié)了三個(gè)最常把a(bǔ)s const用在刀刃上的場景每一個(gè)都直接提升了代碼的可維護(hù)性和類型安全度。3.1 常量表 keyof typeof聯(lián)合類型自動(dòng)生成這是as const最基礎(chǔ)也最實(shí)用的用法。說一個(gè)我自己的使用習(xí)慣。我在項(xiàng)目里經(jīng)常需要定義各種狀態(tài)集合比如任務(wù)的pending / processing / done訂單的unpaid / paid / refunded用戶的active / disabled。最早的寫法是這樣的enum OrderStatus { Unpaid unpaid, Paid paid, Refunded refunded, }后來我發(fā)現(xiàn)enum有幾個(gè)問題。第一它有自己的運(yùn)行時(shí)對象形態(tài)即使只需要字符串編譯產(chǎn)物里也會(huì)多出一個(gè)鍵值映射對象第二在isolatedModules下使用const enum會(huì)有兼容性限制第三它的類型和值是綁定的但字符串和枚舉名之間的映射關(guān)系在代碼里不夠直觀。我現(xiàn)在的首選是as const常量表const ORDER_STATUS { UNPAID: unpaid, PAID: paid, REFUNDED: refunded, } as const; type OrderStatus typeof ORDER_STATUS[keyof typeof ORDER_STATUS]; // unpaid | paid | refunded這行keyof typeof的寫法值得仔細(xì)拆一下。typeof ORDER_STATUS拿到的是對象本身的類型也就是{ readonly UNPAID: unpaid; readonly PAID: paid; readonly REFUNDED: refunded }keyof拿到所有鍵的聯(lián)合UNPAID | PAID | REFUNDED再用索引訪問類型T[K]把每個(gè)鍵對應(yīng)的值取出來得到unpaid | paid | refunded。這套寫法的最大優(yōu)勢是單一數(shù)據(jù)源。哪天產(chǎn)品說要加一個(gè)CANCELLED狀態(tài)你只需要在常量表里加一行const ORDER_STATUS { UNPAID: unpaid, PAID: paid, REFUNDED: refunded, CANCELLED: cancelled, } as const;代碼里所有用到OrderStatus的地方會(huì)自動(dòng)多出一個(gè)合法值。函數(shù)參數(shù)、接口屬性、條件判斷全部聯(lián)動(dòng)。你不需要去搜索哪個(gè)文件里手寫了聯(lián)合類型因?yàn)楦静淮嬖诘诙菪枰降穆暶鳌?.2 事件映射用泛型推斷 payload替代 enum第二個(gè)高頻場景是事件映射。尤其是寫類似 Redux 的 reducer、事件總線、或是游戲引擎里的消息分發(fā)時(shí)as const加泛型可以幫你做一個(gè)非常安全的類型映射。先定義一個(gè)事件表const EVENTS { CLICK: { type: CLICK, payload: { x: number; y: number } }, KEYDOWN: { type: KEYDOWN, payload: { key: string } }, SCROLL: { type: SCROLL, payload: { deltaY: number } }, } as const; type EventMap typeof EVENTS; type EventType keyof EventMap; type EventName EventMap[EventType][type]; // CLICK | KEYDOWN | SCROLL注意因?yàn)閍s const的存在EventMap[EventType][type]能精確推導(dǎo)出CLICK | KEYDOWN | SCROLL。如果沒有as const這里得到的會(huì)是string整個(gè)事件系統(tǒng)就失去了核心約束力。然后可以寫一個(gè)泛型的emit函數(shù)function emitE extends EventName( type: E, payload: EventMap[ExtractEventType, { type: E }][payload] ) { // 分發(fā)邏輯 console.log(type, payload); } emit(CLICK, { x: 1, y: 2 }); // ok emit(CLICK, { key: a }); // 報(bào)錯(cuò)payload 類型不匹配 emit(HOVER, {}); // 報(bào)錯(cuò)不存在的事件名這個(gè)模式的威力在于事件名和 payload 的對應(yīng)關(guān)系完全由數(shù)據(jù)表驅(qū)動(dòng)。你不需要為每個(gè)事件單獨(dú)寫一個(gè)接口不需要在emit函數(shù)里做一串switch窄化。新增事件時(shí)只需要在EVENTS里加一項(xiàng)其他所有調(diào)用點(diǎn)的類型校驗(yàn)立刻生效。如果用enum加各種手動(dòng)接口的方式實(shí)現(xiàn)同樣功能光是維護(hù)事件名和 payload 的同步關(guān)系就夠頭疼的。這也是我在中大型前端項(xiàng)目里力推as const的重要原因。3.3 路由與權(quán)限配置字面量類型把入口參數(shù)鎖死第三個(gè)場景是路由表和權(quán)限表。現(xiàn)在很多前端項(xiàng)目的路由是集中配置的比如這樣的const ROUTES { HOME: /, PROFILE: /profile, SETTINGS: /settings, ADMIN: /admin, } as const; type RoutePath typeof ROUTES[keyof typeof ROUTES]; // / | /profile | /settings | /admin有了RoutePath之后你的navigate函數(shù)可以寫成這樣function navigate(path: RoutePath) { // 跳轉(zhuǎn)邏輯 } navigate(/settings); // ok navigate(/setting); // 報(bào)錯(cuò)拼錯(cuò)了路徑編譯器能攔住 navigate(/profile?id1); // 報(bào)錯(cuò)這個(gè)字符串不是 RoutePath 的成員不要小看這種約束。在一個(gè)有幾十條路由的項(xiàng)目里字符串拼錯(cuò)是家常便飯。如果navigate的參數(shù)是string那這類錯(cuò)誤只能等運(yùn)行時(shí)頁面白屏才能發(fā)現(xiàn)。用它當(dāng)參數(shù)類型之后編譯期就是你的測試員。權(quán)限配置也是同理const ROLES { USER: user, EDITOR: editor, ADMIN: admin, } as const; type Role typeof ROLES[keyof typeof ROLES]; function checkPermission(currentRole: Role, requiredRole: Role) { const roleRank: RecordRole, number { user: 1, editor: 2, admin: 3, }; return roleRank[currentRole] roleRank[requiredRole]; }注意這里RecordRole, number要求你為每一個(gè)角色都提供權(quán)重。如果以后加了個(gè)SUPER_ADMIN但忘了在roleRank里配置TypeScript 會(huì)直接報(bào)錯(cuò)。這種漏寫就報(bào)錯(cuò)的體驗(yàn)是手寫復(fù)雜類型時(shí)要花很多功夫才能達(dá)到的但as const天然就給了你。4. 進(jìn)階組合as const 與 satisfies、模板字面量和遞歸只讀as const單獨(dú)用已經(jīng)很強(qiáng)了但真正讓它發(fā)揮全部價(jià)值的是和其他類型特性聯(lián)動(dòng)。這一節(jié)是整篇文章含金量比較高的部分我把三個(gè)最常用的組合姿勢完整拆解。4.1 as const satisfies結(jié)構(gòu)校驗(yàn)和字面量一步到位satisfies是 TypeScript 4.9 引入的操作符它和as const是天生一對。它解決的是一個(gè)很微妙的矛盾你既要讓 TS 校驗(yàn)常量是否符合某個(gè)接口又不想讓校驗(yàn)過程把字面量類型拓寬成寬泛類型。看下面這個(gè)例子。項(xiàng)目里有一個(gè)國際化文案配置const COPY { title: 你好, description: 歡迎使用, buttonText: 確認(rèn), };你想確保這個(gè)配置滿足接口Recordstring, string于是這樣寫const COPY: Recordstring, string { title: 你好, description: 歡迎使用, buttonText: 確認(rèn), };類型檢查通過了但壞消息是COPY.title現(xiàn)在的類型是string而不是字面量你好。你失去了精確推導(dǎo)。那反過來用as constconst COPY { title: 你好, description: 歡迎使用, buttonText: 確認(rèn), } as const;字面量保住了但結(jié)構(gòu)校驗(yàn)沒有了。如果你在配置里寫錯(cuò)了一個(gè)字段名或者漏了某個(gè)必填項(xiàng)TS 不會(huì)提醒你。satisfies完美解決了這個(gè)兩難const COPY { title: 你好, description: 歡迎使用, buttonText: 確認(rèn), extra: 123, // 報(bào)錯(cuò)number 不能賦給 string } as const satisfies Recordstring, string; type CopyKeys keyof typeof COPY; // title | description | buttonText這段代碼做到了三件事COPY的結(jié)構(gòu)滿足接口要求屬性值保留精確的字面量類型任何不符合接口的項(xiàng)被直接攔下。一個(gè)關(guān)鍵字同時(shí)解決校驗(yàn)和窄化兩個(gè)需求。更具體的場景是配置文件的規(guī)范校驗(yàn)。比如某個(gè)第三方庫的選項(xiàng)對象interface LoggerOptions { level: debug | info | warn | error; prefix?: string; } const options { level: debug, prefix: [main], } as const satisfies LoggerOptions; // options.level 的類型是 debug而不是 debug | info | warn | error注意區(qū)別如果直接用const options: LoggerOptions { ... }options.level的類型會(huì)被拓寬成四個(gè)字的聯(lián)合你用它的地方就不能精準(zhǔn)處理。用了as const satisfies之后結(jié)構(gòu)校驗(yàn)沒丟字面量也保住了。4.2 模板字面量類型從常量表自動(dòng)拼出事件名模板字面量類型和as const的組合能在保持?jǐn)?shù)據(jù)源唯一的前提下自動(dòng)生成更龐大的聯(lián)合類型。舉個(gè)例子。項(xiàng)目里有一組 API 事件命名規(guī)則是資源名加動(dòng)作名比如user:created、order:paid、order:refunded。最自然的做法是定義一組前綴常量const RESOURCES { user: user, order: order, payment: payment, } as const; const ACTIONS { created: created, updated: updated, deleted: deleted, paid: paid, refunded: refunded, } as const;然后這樣生成完整事件名type Resource keyof typeof RESOURCES; type Action keyof typeof ACTIONS; type DomainEvent ${Resource}:${Action}; // user:created | user:updated | user:deleted | user:paid | ...你沒看錯(cuò)TypeScript 會(huì)自動(dòng)枚舉所有Resource和Action的組合生成的聯(lián)合類型多達(dá) 12 項(xiàng)而且每一個(gè)都是合法字面量。這比手寫 12 個(gè)字符串方便得多也比寫一套泛型工具函數(shù)直觀得多。更重要的是這個(gè)聯(lián)合類型完全由RESOURCES和ACTIONS兩個(gè)常量表驅(qū)動(dòng)。當(dāng)RESOURCES里新增一個(gè)admin資源時(shí)DomainEvent自動(dòng)多出admin:created、admin:updated等 5 個(gè)新值。你不需要記得去更新哪個(gè)類型定義因?yàn)樗緛砭蜎]有一個(gè)需要更新的定義。類似的用法還能生成 CSS 類名前綴、權(quán)限組合、路由前綴等。只要命名規(guī)則是固定前綴 固定后綴的組合式模板字符串加as const基本是最優(yōu)雅的解法。4.3 DeepReadonly 要不要寫分情況討論as const只保證一層只讀。這句話很多人知道但知道一層只讀意味著什么的人不多。const nested { user: { name: admin, permissions: [read, write], }, } as const; // nested.user.name 的類型是 admin很好 // nested.user.permissions 的類型是 readonly [read, write]也很好 // nested.user.permissions.push(execute) 會(huì)報(bào)錯(cuò)看起來一切正常。但如果嵌套層數(shù)再深一點(diǎn)呢const config { server: { host: 127.0.0.1, featureFlags: { darkMode: true, beta: false, }, }, } as const;featureFlags的上一層被as const約束了所以config.server是只讀的config.server.featureFlags也是只讀的。這只讀是遞歸傳染的嗎是也不是。準(zhǔn)確地說as const是遞歸作用到對象樹的每一層的。上面的featureFlags內(nèi)部屬性darkMode也確實(shí)被推導(dǎo)成true而不是boolean。所以對普通對象來說完全嵌套的字面量推導(dǎo)是生效的。真正的問題出在數(shù)組上?？催@個(gè)const matrix [[1, 2], [3, 4]] as const; // 類型readonly [readonly [1, 2], readonly [3, 4]] const mutating [[1, 2], [3, 4]] as const; mutating[0].push(5); // 這樣會(huì)報(bào)錯(cuò)嗎讓我算一下。mutating的類型是readonly [readonly [1, 2], readonly [3, 4]]。mutating[0]的類型是readonly [1, 2]它是只讀元組push方法確實(shí)不存在所以會(huì)報(bào)錯(cuò)。對數(shù)組嵌套as const的遞歸推導(dǎo)也是可靠的。那我為什么還要提醒只淺層因?yàn)橐坏┠阌昧似渌愋筒僮鞣@個(gè)遞歸可能被截?cái)唷１热缬昧藄atisfies配合接口類型時(shí)對象會(huì)先經(jīng)歷接口兼容性檢查而接口里的數(shù)組類型如果不是元組就可能被拓寬。還有一個(gè)更隱蔽的場景as const不能阻止對象被整體賦值給可變類型后再修改。const original { value: 1 } as const; // 這里的 target 是可變的 let mutableTarget: { value: number } original; mutableTarget.value 999; // 合法original 沒變但類型被繞過所以如果你真的需要一個(gè) DeepReadonly 類型來配合復(fù)雜嵌套結(jié)構(gòu)自己寫一個(gè)也不難type DeepReadonlyT { readonly [K in keyof T]: T[K] extends object ? T[K] extends readonly unknown[] ? DeepReadonlyT[K] : DeepReadonlyT[K] : T[K]; }; type ReadonlyConfig DeepReadonlytypeof config;但我個(gè)人的建議是不要默認(rèn)給所有東西套 DeepReadonly。絕大多數(shù)業(yè)務(wù)場景下as const自帶的一層只讀已經(jīng)足夠攔截 95% 的誤修改。DeepReadonly 是給底層庫、框架級代碼、領(lǐng)域模型聲明用的重武器用得越多類型計(jì)算越復(fù)雜編譯期負(fù)擔(dān)也隨之上升。工具要用在刀刃上。5. 邊界與陷阱as const 什么時(shí)候會(huì)坑你沒有任何技巧是銀彈as const也一樣。它有三個(gè)比較經(jīng)典的坑以及一些更容易被忽視的邊界我踩過、也看過別人踩過值得拿出來專門講。5.1 解構(gòu)與回調(diào)參數(shù)字面量類型說沒就沒第一個(gè)坑是解構(gòu)和函數(shù)參數(shù)會(huì)丟失部分類型信息。先看解構(gòu)const STATUS { TODO: todo, DONE: done, } as const; // 錯(cuò)誤示范函數(shù)參數(shù)用了 const 斷言對象但斷言的類型會(huì)丟失嗎 function processStatus(status: typeof STATUS[keyof typeof STATUS]) {} // 直接傳值是安全的 processStatus(STATUS.TODO); // ok // 但解構(gòu)出來就可能出問題 const { TODO, DONE } STATUS; processStatus(DONE); // 這里類型是什么實(shí)際上因?yàn)榻鈽?gòu)出來的DONE是用const聲明的TypeScript 會(huì)保留done這個(gè)字面量類型。所以直接這樣用沒問題。真正的坑在數(shù)組解構(gòu)和函數(shù)默認(rèn)值上。看這個(gè)例子const COLORS [red, green, blue] as const; function pickColor(color: typeof COLORS[number]) { // ... } // 解構(gòu)數(shù)組元素 const [firstColor, secondColor] COLORS; pickColor(firstColor); // 類型是 redok數(shù)組解構(gòu)配合const聲明索引元素保持字面量這也還能用。真正的問題出在把元素賦給let變量或者放進(jìn)可變?nèi)萜骼?。let currentColor COLORS[1]; // 類型變成 green | undefined不是 green currentColor COLORS[2]; // 此時(shí)類型拓寬為 blue其實(shí)這里let聲明只是導(dǎo)致后續(xù)可以重新賦值而賦的值也會(huì)被收窄到聯(lián)合成員。真正讓新手困惑的坑是當(dāng)as const的只讀元組被展開到可變上下文時(shí)元組退化為數(shù)組。function splitColors(colors: readonly string[]) { const copy: string[] [...colors]; // ok copy.push(yellow); // ok }我自己在實(shí)戰(zhàn)中遇到最多的問題反而是在useState這類泛型 Hook 里。useState返回的數(shù)組是可變的[state, setState]如果你把一個(gè)as const的元組塞進(jìn)去希望它保持元組類型結(jié)果往往會(huì)變成普通數(shù)組類型const [state, setState] useState([1, 2] as const); // state 的類型推斷不是 readonly [1, 2]而是 number[]這是因?yàn)閡seState的泛型參數(shù)期望的是一個(gè)普通State它的默認(rèn)推斷邏輯會(huì)優(yōu)先用可寫數(shù)組。要保住元組形態(tài)就得顯式給泛型const [state, setState] useStatereadonly [1, 2]([1, 2] as const);這種場景不多但一旦遇到而你不理解原理排查起來很容易繞遠(yuǎn)路。5.2 includes 的嚴(yán)格參數(shù)攔截錯(cuò)別字也攔截了合法輸入第二個(gè)坑更隱蔽。當(dāng)你對as const數(shù)組調(diào)用includes時(shí)參數(shù)類型會(huì)被收窄成聯(lián)合成員。const ALLOWED_TAGS [javascript, typescript, css] as const; function isAllowed(tag: string) { return ALLOWED_TAGS.includes(tag); // 報(bào)錯(cuò)類型 string 的參數(shù)不能賦給類型 javascript | typescript | css 的參數(shù) }這乍看之下很反直覺明明includes應(yīng)該是檢查這個(gè)字符串在不在數(shù)組里怎么反而不讓我檢查任意字符串了原因在于Array.prototype.includes的參數(shù)類型實(shí)際上是searchElement: TT是數(shù)組元素類型。當(dāng)數(shù)組變成readonly [javascript, typescript, css]時(shí)T就是這個(gè)字面量聯(lián)合。TS 認(rèn)為你要查找的值必須來自這個(gè)聯(lián)合如果你傳入一個(gè)不屬于聯(lián)合的string它覺得你根本沒可能找到肯定是寫錯(cuò)了。問題是實(shí)際場景里我們可能真的需要用外部輸入來判斷。比如用戶從表單里輸入一個(gè)標(biāo)簽我們要檢查它是否合法。這時(shí)候includes反而會(huì)擋住你。業(yè)內(nèi)常用的解決方案有幾個(gè)我推薦第一個(gè)// 方案一把檢查目標(biāo)斷言為聯(lián)合類型 function isAllowed(tag: string) { return (ALLOWED_TAGS as readonly string[]).includes(tag); } // 方案二用 Set 代替數(shù)組 const allowedTagSet new Setstring(ALLOWED_TAGS); function isAllowed(tag: string) { return allowedTagSet.has(tag); } // 方案三手動(dòng)寫一個(gè)類型守衛(wèi) function isAllowed(tag: string): tag is typeof ALLOWED_TAGS[number] { return (ALLOWED_TAGS as readonly string[]).includes(tag); }方案三是我最推薦的因?yàn)樗粌H解決了檢查問題還讓調(diào)用方的 TypeScript 知道一旦isAllowed返回true后續(xù)代碼里的tag就自動(dòng)收窄為合法標(biāo)簽聯(lián)合類型。這種守衛(wèi) 收窄的組合是as const類型體系里很好用的一環(huán)。5.3 淺層只讀的誤導(dǎo)嵌套對象改起來沒人攔前面我講過as const對嵌套對象是遞歸的但依然有個(gè)容易誤解的地方只讀約束是類型層面的不是運(yùn)行時(shí)層面的?？催@段代碼const nestedConfig { database: { host: localhost, port: 5432, }, } as const; // TypeScript 層面下面這行會(huì)報(bào)錯(cuò) // nestedConfig.database.port 5433; // 報(bào)錯(cuò)不能分配到只讀屬性TS 會(huì)攔這沒問題。但如果有人用類型斷言繞過檢查const mutableConfig nestedConfig as { database: { host: string; port: number }; }; mutableConfig.database.port 9999; // 運(yùn)行時(shí)不報(bào)錯(cuò)這一行運(yùn)行時(shí)完全正常nestedConfig.database.port在運(yùn)行時(shí)變成了 9999。雖然類型系統(tǒng)里它依然是5432但實(shí)際值已經(jīng)變了。這就是類型層面的只讀不等于運(yùn)行時(shí)凍結(jié)。很多初學(xué)者誤以為as const的效果等同于Object.freeze這是完全錯(cuò)誤的。Object.freeze是運(yùn)行時(shí)特性會(huì)真正阻止屬性寫入而as const只是類型層面的標(biāo)記編譯后消失。如果你的數(shù)據(jù)要和不可靠的第三方庫交互或者會(huì)被序列化后經(jīng)過某些會(huì)修改對象的中間層那as const的只讀保護(hù)其實(shí)是很脆弱的。那它還有用嗎當(dāng)然有。它的意義在于在你自己的代碼范圍內(nèi)TypeScript 能提前發(fā)現(xiàn)修改意圖幫你養(yǎng)成不修改常量的習(xí)慣。至于運(yùn)行時(shí)層面的不可變性如果需要請用Object.freeze但別指望類型層面的約束能防住所有運(yùn)行時(shí)篡改。5.4 真的要可變配置時(shí)別硬上 as const最后一個(gè)邊界是使用場景的判斷。as const很好但不代表所有常量都應(yīng)該加它。如果你的配置確實(shí)需要在運(yùn)行時(shí)被修改比如一個(gè)熱更新的標(biāo)志位、一個(gè)動(dòng)態(tài)變化的主題配置、一個(gè)由后端返回后還要加工的數(shù)據(jù)那加as const只會(huì)讓你到處寫類型斷言去繞過只讀約束反而把代碼弄得很難看。// 這種就不適合加 as const let dynamicConfig { features: [darkMode], retryCount: 3, };一個(gè)實(shí)用的判斷標(biāo)準(zhǔn)是問自己這個(gè)值在定義之后我是否希望它永遠(yuǎn)不變?nèi)绻鸢甘鞘羌觓s const如果答案是它其實(shí)會(huì)變只是目前沒變那別加老老實(shí)實(shí)寫一個(gè)顯式類型接口讓可變的語義在類型里清晰表達(dá)出來。我在維護(hù)的某個(gè)老項(xiàng)目里見過一個(gè)反面案例團(tuán)隊(duì)為了追求高級技巧把應(yīng)用配置全部加了as const結(jié)果每次動(dòng)態(tài)更新開關(guān)都要改成let并重新斷言代碼里塞滿了as、ts-ignore和嵌套的解構(gòu)拷貝。類型安全沒有提升反而因?yàn)榧s束過強(qiáng)導(dǎo)致所有人都在繞路。工具是為人服務(wù)的不是為炫技服務(wù)的。6. 關(guān)于編譯性能的實(shí)測與體會(huì)as const 會(huì)拖慢 tsc 嗎既然標(biāo)題里有性能完全總結(jié)那編譯性能這個(gè)話題繞不開。很多團(tuán)隊(duì)在選擇是否使用as const時(shí)會(huì)擔(dān)心這種類型斷言會(huì)不會(huì)讓 tsc 和 IDE 變慢我用實(shí)際經(jīng)驗(yàn)說說結(jié)論。6.1 類型檢查器如何看待字面量類型先給一個(gè)明確的結(jié)論普通使用as const基本不會(huì)對編譯性能產(chǎn)生可感知的影響。原因是as const產(chǎn)生的字面量類型和只讀元組在類型檢查器內(nèi)部是相對簡單的結(jié)構(gòu)。它就相當(dāng)于告訴編譯器這里是一個(gè)固定值。檢查一個(gè)賦值是否符合todo | done比檢查一個(gè)復(fù)雜泛型參數(shù)推導(dǎo)要快得多。類型檢查的性能瓶頸從來不在字面量數(shù)量多上而在類型計(jì)算復(fù)雜度高上。真正拖慢編譯的是泛型遞歸、模板字面量類型的大規(guī)模組合、超大的聯(lián)合類型、交叉類型的一層層化簡。這些恰恰是satisfies、DeepReadonly、模板字面量類型這些進(jìn)階組合可能引入的。所以如果你感覺項(xiàng)目加了as const后編譯變慢了更可能的原因是你在同一個(gè)文件里同時(shí)用了大量高級類型工具而不是as const本身。6.2 用 extendedDiagnostics 量化如果你確實(shí)想量化TypeScript 官方提供了編譯診斷工具npx tsc --extendedDiagnostics跑完之后會(huì)輸出一份檢查時(shí)間報(bào)告其中這幾項(xiàng)值得關(guān)注Files: 245 Types: 1820 Instantiations: 3210 Memory used: 54210 kB I/O read time: 0.42s Parse time: 2.13s Bind time: 0.68s Check time: 5.12s Emit time: 1.08s Total time: 9.43sTypes是類型實(shí)例的總數(shù)Instantiations是泛型實(shí)例化的次數(shù)這一項(xiàng)最能反映類型計(jì)算的負(fù)擔(dān)Check time是類型檢查的總時(shí)長。你可以挑兩個(gè)文件一個(gè)用as const函數(shù)一個(gè)不用分別測Check time的變化。我實(shí)測的經(jīng)驗(yàn)是在同一個(gè)項(xiàng)目里增刪幾十處as constCheck time的變化通常不超過 0.1 秒。而如果你加了十幾個(gè)模板字符串類型的深層遞歸Instantiations可能會(huì)翻好幾倍。6.3 真正拖慢編譯的是哪些東西我把這幾年遇到過的編譯變慢的元兇排了個(gè)序前幾名幾乎沒有一個(gè)是as const本身造成的深度遞歸的映射類型比如DeepReadonly在大型接口上無限遞歸編譯期要反復(fù)展開模板字面量類型的笛卡爾積${A}${B}這種寫法會(huì)生成龐大聯(lián)合如果 A 有 20 個(gè)成員、B 有 30 個(gè)成員瞬間就有 600 種組合需要檢查巨型聯(lián)合類型超過幾百個(gè)成員的聯(lián)合在每次 assignability 檢查時(shí)都要逐一比對泛型函數(shù)調(diào)用鏈一層層泛型推斷每一步都要做復(fù)雜的上下文派生。有意思的是第 2 條和第 3 條經(jīng)常和as const一起出現(xiàn)。比如我用as const生成了 600 個(gè)合法字符串的聯(lián)合類型然后在emit函數(shù)里做分發(fā)這是進(jìn)階玩法也會(huì)帶來類型檢查開銷。但這是進(jìn)階玩法的代價(jià)不是as const的代價(jià)。我的建議是保持as const在常量表和普通對象上的日常使用放心大膽用但如果你需要寫那種遞歸映射類型或模板字面量大型組合要有意識(shí)地控制規(guī)模并做好性能觀測。6.4 組織好你的類型才是最大的性能優(yōu)化最后我想說一個(gè)容易被忽略的點(diǎn)真正的編譯性能優(yōu)化不取決于用不用as const而取決于你如何組織類型。as const的價(jià)值恰恰是讓值成為類型的來源減少手寫重復(fù)類型。項(xiàng)目里手寫的重復(fù)類型越少類型系統(tǒng)需要處理的冗余結(jié)構(gòu)就越少編譯檢查的負(fù)載自然越低。從這個(gè)角度看合理使用as const不僅不是編譯性能的負(fù)擔(dān)反而是間接幫助編譯器減輕工作量的手段。我也遇到過另一個(gè)極端一個(gè)團(tuán)隊(duì)為了統(tǒng)一管理類型把幾十個(gè)常量表里的幾百個(gè)常量全部塞進(jìn)一個(gè)types.ts的as const巨對象里然后用一堆Extract和模板字面量去拆分成各種類型。結(jié)果每次改動(dòng)這個(gè)文件幾乎所有依賴它的文件都要重新做一輪類型檢查編譯時(shí)間肉眼可見地上升。這就屬于把類型源頭變成類型瓶頸的錯(cuò)誤組織方式。正確的做法是把常量表按業(yè)務(wù)域拆開每個(gè)域單獨(dú)一個(gè)文件用as const保持單源再用satisfies做結(jié)構(gòu)校驗(yàn)。這樣每次改動(dòng)只影響相關(guān)業(yè)務(wù)域的類型檢查范圍編譯時(shí)間保持穩(wěn)定代碼的模塊邊界也更清晰。最后再分享一個(gè)我個(gè)人的實(shí)戰(zhàn)習(xí)慣。我在團(tuán)隊(duì)里推行as const時(shí)不會(huì)一上來就要求所有人把所有常量都改造成這種寫法。我會(huì)先挑一個(gè)高頻使用的狀態(tài)常量表做范例把typeof STATUS[keyof typeof STATUS]這種索引類型寫清楚讓大家看到改一處、全局聯(lián)動(dòng)的效果。大部分人用過一次之后就會(huì)自發(fā)地在其他地方應(yīng)用起來因?yàn)檫@種值即類型的體驗(yàn)確實(shí)舒服。另外如果你已經(jīng)開始用as const請務(wù)必記住配套的satisfies和keyof typeof這三件套。它們不是花哨的語法糖而是讓常量表同時(shí)具備結(jié)構(gòu)校驗(yàn)字面量精確和聯(lián)合類型自動(dòng)生成三種能力的完整方案。用熟了之后你會(huì)發(fā)現(xiàn)很多曾經(jīng)需要手寫泛型工具類型的場景其實(shí)用這三個(gè)基礎(chǔ)特性組合一下就足夠了。