題幹與適用場景
一個前端工具鏈團隊維護大型 TypeScript 應用，某個分析模組在匯入時註冊全域監聽器並讀取環境設定，導致首屏啟動變慢。團隊想用 TypeScript 5.9 支援的 import defer 延後副作用，但建置產物仍需運行在不支援該語法的舊執行時。請解釋模組載入、模組求值、存取觸發點與遷移閘門。
TypeScript 5.9 文件說明，import defer 只允許命名空間匯入；模組及其依賴會先載入，但模組程式碼要到存取命名空間成員時才求值。TypeScript 不會將它降級轉換，只有 preserve 或 esnext 模組模式適合直接保留該語法。
面試官考察點
面試官會關注你是否區分載入與求值、靜態匯入與動態匯入，是否能識別全域註冊與環境讀取等副作用。高品質回答還應涵蓋 bundler、舊瀏覽器、SSR、預載、測試隔離與回滾策略，而不是只把 import defer 當成更短的延遲載入寫法。
回答前需要釐清的問題
- 目標執行時與 bundler 是否原生理解
import defer？ - 模組副作用能否安全延後，還是必須在啟動階段完成？
- 哪個匯出成員會觸發求值，是否存在隱藏的頂層存取？
- SSR、客戶端 hydration、預載與測試是否要求固定執行順序？
- 遷移失敗時能否切回普通靜態匯入或動態
import()？
30 秒回答
「我會先把 import defer 定義為延後求值，不把它等同於動態載入。TypeScript 5.9 要求命名空間匯入，模組資源仍會載入，第一次存取命名空間成員才執行模組程式碼；編譯器不會為舊執行時自動降級。因此我會先稽核頂層副作用與 SSR 順序，在支援該語法的 bundler 與執行時做小流量實驗，同時保留普通匯入或動態 import() 開關。只有建置、hydration、效能與副作用測試都通過，才擴大範圍。」
分步驟深入解答
1. 先固定語義與版本
記錄 TypeScript 5.9 版本、目標模組模式與 TC39 提案狀態。回答中明確：資源載入與模組求值是兩件事；import defer 延後後者，不能承諾網路請求一定延後。把兩個時間點分別打點，避免用首屏網路瀑布圖推斷程式沒有執行。
2. 說明語法邊界
只有命名空間匯入可以延後求值，不能寫預設匯入或具名匯入。存取命名空間屬性時觸發模組求值，因此成員讀取本身成為可觀察的執行邊界。
import defer * as analytics from "./analytics.js";
// 模組檔案已載入，但頂層註冊尚未執行。
export function openPanel() {
analytics.start(); // 第一次存取成員時觸發求值。
}如果呼叫點需要在 analytics.start 之前完成全域註冊，延後求值會改變行為；此時應保留普通匯入，或把初始化改成明確函式。
3. 與動態 import 對照
動態 import() 通常回傳 Promise，並把載入與求值放進非同步流程；import defer 保持靜態模組關係，資源可提前載入，卻延後頂層程式碼執行。兩者在錯誤傳播、預載、打包切分、SSR 與測試時序上不同，不能只改名稱後直接比較首屏指標。
4. 檢查副作用與存取圖
列出頂層副作用：事件監聽器、單例註冊、環境變數讀取、polyfill、遙測初始化與快取填充。沿所有命名空間成員存取點畫圖，找出 hydration、路由預取或測試 setup 中的隱式存取。若必須控制順序，把副作用搬進明確的 initialize()，讓呼叫方決定時機。
5. 處理建置與執行時相容
TypeScript 不會將 import defer 降級。為支援舊執行時，應確認 bundler 能轉換或拒絕該語法；不能轉換時保留普通匯入或動態 import() 實作。CI 至少涵蓋目標瀏覽器、Node SSR、開發伺服器、生產打包、source map、程式碼切分與錯誤邊界。
6. 設定上線與回滾閘門
用功能開關選擇 deferred、靜態與動態三種路徑，記錄首屏互動延遲、模組求值耗時、重複初始化與 hydration 錯誤。任何順序變化、舊執行時語法錯誤或指標回退都關閉開關並回到穩定匯入；不要在提案或工具鏈仍變動時修改公共套件的模組契約。
高品質示範回答
我會先確認 TypeScript 5.9 與目標執行時的支援矩陣，再把匯入模組的頂層副作用列成清單。import defer 只支援命名空間匯入，模組可以先載入，第一次存取成員才求值，TypeScript 不負責降級；因此網路載入、執行時機與動態 import() 必須分別量測。實驗同時覆蓋 SSR、hydration、舊瀏覽器、bundler、測試隔離與重複初始化，並用功能開關保留普通匯入回滾。只有語義順序、建置產物與效能資料穩定後，才擴大遷移。
常見錯誤
- 把
import defer當成動態import()→ 忽略靜態依賴與 Promise 時序 → 分別驗證載入、求值與錯誤傳播。 - 使用預設或具名匯入 → 違反 TypeScript 5.9 語法邊界 → 只用命名空間匯入並在存取點觸發。
- 假設 TypeScript 會自動轉譯 → 舊執行時直接語法失敗 → 驗證 bundler 轉換能力並保留回退路徑。
- 忽略頂層副作用 → 監聽器、polyfill 或遙測初始化時序改變 → 改成明確初始化或保留普通匯入。
- 只看首屏網路請求 → 資源載入提前不代表程式碼執行提前 → 分別記錄載入與求值時間。
追問及應對
為什麼 import defer 只允許命名空間匯入？
命名空間物件提供明確的屬性存取邊界；預設或具名匯入會在繫結階段暴露具體值，無法保持「第一次存取成員才求值」的統一語義。
它和程式碼切分是同一件事嗎？
不是。程式碼切分決定資源如何拆包與載入，import defer 主要改變模組程式碼何時求值；資源可能已經載入或預取。
SSR 應該如何處理？
確認伺服器與客戶端的求值順序一致，避免伺服器已註冊全域狀態而客戶端尚未註冊。必要時在伺服器保留靜態匯入，或把初始化改成明確且可重複呼叫的函式。
如何測試副作用只執行一次？
在隔離的測試程序中記錄模組初始化計數，分別涵蓋未存取、首次存取、重複存取、並行存取與測試 teardown，驗證單例與監聽器不會重複註冊。
什麼時候不應採用它？
當執行時或 bundler 不支援、模組必須在啟動階段完成副作用、SSR 順序不可改變，或效能收益無法重複時，繼續使用普通匯入或動態 import()。