Rust 面試題：如何遷移到 1.97 的 v0 符號改名格式？

題幹與適用場景

Rust 1.97 在 stable 上預設啟用 Rust 專用的 v0 symbol mangling。v0 能可逆表達泛型等資訊，但它不是 Rust 的穩定 ABI，也沒有標準化的 demangled 輸出；舊版 legacy 格式只能在 nightly 上切回。題目假設一個 workspace 仍有舊工具、增量快取、預編譯庫和 C FFI，要求安全遷移符號檢視、崩潰分析和發布流程。

這是一道 coding/toolchain 題，不是要求背出 v0 grammar。崗位包括基礎設施、編譯工具、效能分析和需要維護 native 依賴的 Rust 工程師。核心目標是辨認哪些符號可以改變、哪些外部契約必須保持，以及如何用可重現的建置驗證遷移。

面試官考察點

• 能否區分內部 Rust symbol 與由 #[nomangle]、#[exportname] 或 extern 暴露的 FFI 名稱。
• 能否說明 v0 的可讀性、泛型資訊和 forward compatibility，同時承認它不是穩定 ABI。
• 能否設計工具鏈相容、快取隔離、混合建置檢測和回滾，而不是只升級 compiler。
• 能否用樣本 binary、debugger、demangler 和符號 diff 驗證真實影響。

普通回答會說「更新 demangler 就好」。強回答會先畫出符號消費者，再定義相容窗口與不變量，最後演練舊產物、新產物和跨平台發布。

回答前需要釐清的問題

1. 哪些消費者讀取符號？包括 debugger、profiler、崩潰收集器、size 分析器、建置快取和腳本。不同消費者可能支援不同格式。
2. 遷移對象是原始碼重編譯，還是必須繼續連結已有 .a、.so 或 .rlib？前者可統一升級，後者需要明確相容窗口和重建邊界。
3. FFI 是否依賴 Rust 私有符號？若 C 端按穩定匯出名連結，應使用明確外部名稱，不能把 Rust 內部 mangled symbol 當 ABI。
4. 是否要保留舊版本崩潰報告的解析能力？若要保留，符號伺服器和 demangler 必須能按 build ID 選擇舊、新格式。

30 秒回答框架

「我先盤點符號的消費者與契約：Rust 內部符號可以隨 compiler 改變，FFI 匯出名必須由明確名稱保護。然後把 compiler、linker、demangler、debugger 和建置快取固定在可重現矩陣裡，分別產生 legacy 與 v0 樣本並做符號 diff。符號伺服器按 build ID 保留舊報告解析路徑，新建置使用支援 v0 的工具。遷移期間禁止混用未標記的快取和預編譯庫；發現工具不支援就暫停發布或縮小範圍。最後用 C FFI、崩潰回溯、效能取樣、可重複建置和回滾演練驗證。」

分步驟深入解答

1. 畫出符號邊界

Rust compiler 會為內部 item 產生 mangled name，linker 用它們在 object 與函式庫之間建立引用。#[nomangle] 可關閉某個 item 的改名，#[exportname] 可指定精確匯出名；extern 相關宣告也可使用連結名控制。遷移的第一條不變量是：C、C++ 或穩定外掛介面只依賴明確外部名稱，不依賴 Rust 泛型或模組路徑編碼。

2. 明確 v0 的承諾與限制

v0 以 _R 開頭，能無歧義編碼泛型和路徑資訊，demangler 可還原有用的實例上下文。但 rustc 文件明確它不是穩定 ABI，demangled 形式也沒有標準。工具只能把它當成可解析的診斷格式；不能把 v0 字串寫進跨版本協定、設定或持久化資料庫作為穩定識別。

3. 建立相容矩陣

矩陣至少包含 Rust 版本、target、debug/release、工具版本、舊函式庫來源和最終消費者。對每個組合保存一份小 binary，列出匯出符號、回溯、取樣器識別結果和建置雜湊。compiler、linker 與 demangler 必須透過鎖定檔或容器固定，避免把「格式變化」和「工具升級」混成一個變數。

build_id -> rustc version -> target -> mangling format -> debug toolchain

4. 隔離快取和混合產物

把 Rust 版本、target、profile 和必要的 codegen 選項納入快取鍵。升級後不要讓舊 .rlib、增量目錄或產生的符號索引被新建置悄悄重用；先清理或明確分桶，再比較完整重建結果。預編譯函式庫必須帶來源版本和建置中繼資料，連結失敗時優先檢查產物混用，而非強行退回舊 compiler。

5. 保護 FFI 與外掛契約

對外的函式、靜態變數和回呼使用固定匯出名，配套 C header、版本檢查和最小 ABI 測試。Rust 內部實作可以改名、移動模組或改變泛型，只要外部名稱、配置、呼叫約定和錯誤語意保持不變。若外掛系統直接尋找 Rust 私有符號，應先改成穩定 shim，再遷移 compiler。

6. 設計遷移、發布和回滾

先在 canary target 用 v0 重建，保留舊版符號伺服器和報告解析。每個 build ID 上傳 debug symbols，並在發布前驗證崩潰回溯、profiler、size 工具和 C FFI。若任一關鍵消費者無法解析 v0，回滾的是發布產物或工具鏈矩陣，不是把 v0 當成穩定 ABI；修復工具後再擴大範圍。

高品質示範回答

「我會把這次升級當成診斷格式遷移，而不是 ABI 升級。先盤點 debugger、profiler、崩潰平台、size 工具、快取和預編譯函式庫，給每個 build ID 記錄 rustc、target 和格式。Rust 1.97 的 v0 可以更完整地表達泛型，但文件也說明它不是穩定 ABI，demangled 輸出沒有標準，所以我不會把內部符號名寫進協定。

「FFI 先做不變量檢查：C 端連結的函式使用 #[export_name] 或穩定 shim，配置和呼叫約定有獨立測試。然後固定 compiler 與分析工具，產生舊格式和 v0 的樣本，比較匯出符號、回溯和 profiler 結果。快取按 compiler、target、profile 和 codegen 選項隔離，舊 .rlib 不與新產物混用。canary 發布時同時保留舊符號解析和回滾路徑；只有所有關鍵消費者都能解析且可重複建置通過，才擴展到全量。」

常見錯誤

• 錯誤表現： 把 v0 symbol 當成穩定 ABI。→ 失敗原因： Rust 文件明確 v0 不是穩定 ABI，未來格式可擴充。→ 修正方法： FFI 使用明確匯出名，把內部符號只用於診斷。
• 錯誤表現： 直接重用舊增量快取。→ 失敗原因： 新舊 compiler 與格式可能在同一快取目錄混合，問題難以重現。→ 修正方法： 把工具鏈與 target 納入快取鍵，升級時先清理或分桶。
• 錯誤表現： 只升級 demangler，不測 debugger 和 profiler。→ 失敗原因： 不同消費者可能支援不同版本或只解析部分資訊。→ 修正方法： 用代表性 binary 做端到端矩陣測試。
• 錯誤表現： 用 nightly 的 legacy 選項作永久方案。→ 失敗原因： stable 不提供同樣的回退承諾，工具鏈升級會再次暴露問題。→ 修正方法： 修復消費者或縮小發布範圍，把回退當短期止損。

追問及應對

舊版 .so 必須繼續服務，新版 Rust 也要發布，怎麼辦？

先確認 .so 的公開邊界。若 C ABI 只依賴穩定匯出名，新版 Rust 可以單獨建置並行部署；若依賴 Rust 私有符號，就先建立 shim 或暫緩替換。兩種產物都帶 build ID、工具鏈資訊和獨立符號索引，禁止只憑檔名混用。

崩潰平台只能解析 legacy，如何推進？

保留舊產物的解析能力，同時為 v0 建立離線解析和回溯驗證。若平台不能在發布前支援，先把 v0 限於不會產生外部報告的 canary，或暫緩該 target；不要透過刪除 debug symbols 讓問題消失。

為什麼不能把 demangled 名稱當指標維度？

它不是穩定標準，compiler、泛型實例和 demangler 版本都可能改變文字。指標應使用 build ID、函式地址正規化規則或工具提供的穩定映射；若必須展示名稱，記錄原始 mangled name 與工具版本，避免跨版本直接比較。