Rust 是由 Rust 專案社群維護的系統程式語言，專案儲存庫於 2010 年 6 月建立，目前累積 119,760 顆星標、18,403 次複製，具名貢獻者超過 440 位，授權為 Apache-2.0。1.99.0 版本於 2026 年 10 月 1 日發佈，相隔 1.98.1（9 月 3 日）約一個月，維持每六週一個版本的節奏。
這個版本最受關注的改動，是把 C 語言可變參數函式定義推向穩定，並同時納入裸函式與可變參數的組合能力；此外還有 Cargo 建置設定、工作區相依覆寫、Rustdoc 效能與多項相容性調整。本文依據官方版本公告、儲存庫統計與公開文件整理，先說明專案定位，再依序分析語言層改動、建置工具變化、文件工具效能、專案數據，以及升級前需要留意的相容性項目。
Rust 1.99.0 是什麼？
Rust 1.99.0 於 2026 年 10 月 1 日發佈，維持六週節奏，累積語言、編譯器、標準函式庫與 Cargo 改動，重點是穩定 C 語言可變參數函式。
Rust 的定位是兼顧效能與記憶體安全的系統程式語言，主要應用於作業系統、嵌入式、命令列工具與高效能服務端。專案自 2015 年釋出 1.0 版後，固定以六週為週期推出新版本，並且在升級路徑上提供向後相容保證，使企業與開源專案可以在低風險前提下持續跟進。
版本編號的推進方式也反映這套節奏。1.98.0 於 2026 年 8 月 20 日推出，1.98.1 為 9 月 3 日的修補版，1.99.0 則落在 10 月 1 日。這種「大版本加小修補」的組合，讓安全修正可以較快送達使用者，同時把功能變更集中在固定的發佈點，方便下游專案安排升級窗口。
Rust 1.99.0 在語言層面有哪些重要改動？
本版穩定 C 語言可變參數函式定義與 #[unsafe(naked)] 組合；另新增預設關閉的檢查，以及讓屬性巨集標註外部模組。
C 語言可變參數函式的穩定化，是本次最具代表性的語言層改動。官方版本公告將「穩定 C 語言可變參數函式定義」列為語言分類項目，同時讓以 #[unsafe(naked)] 撰寫的可變參數函式一併進入穩定狀態。這意味著需要直接對接 C 函式庫、或需要自訂裸函式進入點的專案，可以在穩定版工具鏈上完成，而不必再依賴 nightly 功能旗標。
模組與巨集層面亦有進展。官方允許 #[my_macro] mod foo; 這種寫法穩定使用，使自訂屬性巨集或衍生巨集可以在函式主體之外標註外部模組檔案，對需要大量程式碼生成的框架作者而言，可讀性與組織方式都更具彈性。此外，本版新增一個預設關閉的 raw_borrows_via_references 檢查，用於找出「參照立即衰減為裸借用」的寫法，因為這類寫法常與不安全程式碼的誤用相關。
其他語言層調整偏向修正與收斂。官方擴充了 unconditional_panic 檢查的範圍，使其涵蓋切塊或視窗大小為零時必然恐慌的函式呼叫；同時明確保證 UnsafeCell 的內容可以不經由 get 存取，並相應調整 invalid_reference_casting 檢查。這些變更多數以檢查形式呈現，讓既有程式碼在編譯時獲得提示，而非直接中斷建置。
Rust 1.99.0 對 Cargo 建置流程帶來什麼變化？
Cargo 新增內建 debug 建置設定，為把 dev 移出除錯用途做準備；另允許 2024 版以上成員覆寫繼承的 default-features 欄位。
Cargo 層面的第一項改動是新增名為 debug 的內建設定。官方說明目前它與 dev 設定沒有差異，此舉是為日後把 dev 從除錯用途轉向更合理的開發預設值做準備。對一般專案而言，這代表短期內沒有行為變動，但長期下來建置設定的語意會更貼近實際用途。
第二項改動與工作區相依管理有關。使用 2024 版或更新版本的成員套件，現在可以覆寫從工作區繼承而來的 default-features 欄位。實際效果是當工作區層級啟用了預設功能，成員仍可透過 default-features = false 關閉，這在需要精簡相依樹的函式庫專案中相當實用；若使用較早版本，該設定會被忽略並顯示警告。
Rust 1.99.0 為什麼特別提到 Rustdoc 的效能？
Rustdoc 改進 trait 實作過濾邏輯，官方指平均約 20% 效能提升，並新增 unused_footnote_definition 檢查。
文件工具的效能是本次較容易被忽略、但影響面廣的改動。官方在 Rustdoc 分類說明，透過更聰明的 trait 實作過濾方式，產生文件的速度平均提升約 20%，在部分真實專案上最高可達 40%。對相依數量龐大、文件產生時間偏長的專案而言，這項改動會直接反映在持續整合流程的耗時上。
Rustdoc 同時新增 unused_footnote_definition 檢查，用於找出已定義但未被引用的註腳。這類檢查屬於文件品質維護，對於長期累積大量註解的大型儲存庫，可減少文件中的殘留內容。此外，編譯器在提供「找不到方法」的建議時，現在會優先採用文件別名中完全相符的名稱，而非依賴相似度搜尋；官方指出若專案使用者常以不同名稱尋找某方法，加上文件別名可同時改善編輯器建議與文件搜尋結果。
Rust 1.99.0 的專案數據與維護規模如何？
專案累積 119,760 顆星標、18,403 次複製、逾 440 位貢獻者，授權 Apache-2.0，主要語言 Rust；最近推送為 2026 年 10 月 12 日。
專案規模方面，儲存庫星標數為 119,760 顆，複製數 18,403 次，具名貢獻者超過 440 位，追蹤者 1,551 位，未解決議題約 12,576 項。主要語言為 Rust，授權採 Apache-2.0，儲存庫大小約 1,022,024 KB，建立時間為 2010 年 6 月 16 日，最近一次程式碼推送時間為 2026 年 10 月 12 日，顯示開發活動維持高頻。
Rust 1.99.0 的相容性風險有哪些？
升級前須注意舊式整數模組已棄用、no_mangle_generic_items 升為硬性錯誤、Pin::new_unchecked 契約微調。
相容性項目集中在本版公告的 Compatibility Notes 分類。首先，舊式整數模組已完全棄用，例如 std::i32::MAX 應改以 i32::MAX 存取。其次，no_mangle_generic_items 由警告升級為硬性錯誤，若專案中仍有對泛型項目標註 no_mangle 的程式碼，升級時會直接建置失敗。
第三項與不安全程式碼的契約有關。Pin::new_unchecked 的安全不變條件有輕微調整，實作 UnsafeCell 或自訂指標包裝型別的專案需要重新檢視相關假設。此外，產生值的型別帶有泛型時，常數求值會被中止；文件中「屬性未套用至任何項目」的情況，在文件註解程式碼區塊裡由提示改為錯誤。這些變更多數有清楚的修正方向，建議在升級前先以最新工具鏈執行一次完整建置與測試。
Rust 1.99.0 有哪些平台支援變化？
本版把 riscv64-unknown-linux-musl 提升為第二級並附帶主機工具，同時在全部 gnu 目標上啟用靜態位置無關可執行檔。
平台支援方面，官方將 riscv64-unknown-linux-musl 提升至第二級，並包含主機工具。第二級代表該目標獲得自動化建置與測試覆蓋，對在 RISC-V 平台上使用 musl 執行環境的嵌入式與伺服器專案，可減少自行維護工具鏈的成本。官方同時在全部 gnu 目標上啟用靜態位置無關可執行檔，這項調整與載入時位址配置的安全性有關。
編譯器層面另有一項與嵌入裝置相關的改動：-Ctarget-cpu 被轉換為 AVR、AMDGCN 與 NVPTX 的目標修飾項，使不同目標架構可以用一致方式描述處理器特性。標準函式庫本版亦穩定 17 項 API，包含 Box<[T; N]> 的 IntoIterator 實作、VecDeque::retain_back、Vec::into_parts 與 Vec::from_parts、core::ffi::VaList，以及 std::fs::set_times 與 std::fs::set_times_nofollow 等檔案時間操作。
出處連結有哪些？
本文資料來源為 Rust 程式語言官方儲存庫 rust-lang/rust 的版本公告與公開統計，版本詳情可於官方 1.99.0 發佈說明查閱。
Rust 程式語言的官方儲存庫位於 github.com/rust-lang/rust，版本公告與完整變更清單可在該儲存庫的 Releases 頁面查閱。本文引用的語言層改動、Cargo 與 Rustdoc 變更、穩定化 API 清單及相容性項目，均取自官方 1.99.0 發佈說明；星標、複製、貢獻者與推送時間等數據取自 GitHub 公開統計，擷取時間為 2026 年 10 月 13 日。
總結：Rust 1.99.0 適合什麼團隊升級？
需要與 C 函式庫互通或控制裸函式進入點的團隊最值得升級；一般專案則建議先檢視舊式整數模組與 no_mangle 用法，再以最新工具鏈完整建置測試。
Rust 1.99.0 的價值集中在跨語言介面與工具鏈效率兩端。對需要直接對接 C 函式庫、或以裸函式控制進入點的專案，C 語言可變參數函式定義的穩定化移除了長期依賴 nightly 的障礙；對建置與文件流程較重的團隊，Cargo 的工作區相依覆寫與 Rustdoc 平均約 20% 的效能提升也會逐步反映在流程耗時上。
至於一般應用專案，本版沒有強制性的破壞改動，風險主要來自已宣告的相容性項目。建議升級前先檢查是否仍使用舊式整數模組路徑、是否對泛型項目標註 no_mangle，以及是否有依賴 Pin::new_unchecked 契約的封裝型別，完成後以最新穩定工具鏈執行完整建置與測試，再決定是否納入正式流程。