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