Bazel 發布模型Release Model完全指南Rolling 與 LTS 雙軌制、版本號規則與發布流程【免費下載鏈接】bazela fast, scalable, multi-language and extensible build system項目地址: https://gitcode.com/GitHub_Trending/ba/bazel本文以 Bazel 官方 Release Model 文檔 為主體系統講解 Bazel 自 4.0 起采用的滾動發布Rolling 長期支持LTS雙軌發布模型包括支持矩陣與四個支持階段、major.minor.patch語義化版本規則、兩類發布軌道各自的節奏與完整發布流程以及如何用 Bazelisk 對回歸問題做二分定位。讀完本文你將能夠看懂 Bazel 任意版本號背后的含義、判斷某個版本當前處于什么支持狀態并理解從基線提交到正式發布的全過程及其中的 cherry-pick 與 release candidate 機制。雙軌發布模型Rolling 與 LTSBazel 4.0 及更高版本提供兩條發布軌道release track滾動發布Rolling releases從主分支HEAD直接發布每兩周左右一個版本是下一個 LTS 版本的預覽。滾動發布可以與 Google 內部的 Blaze 發布保持同一基線baseline。長期支持發布LTS releases每約 12 個月從 HEAD 切出一個新的主版本成為當期的 Active 版本并在隨后數年內依次經歷 Maintenance、Deprecated 階段為用戶提供可預期的長期支持窗口。從倉庫結構可以佐證這套模型的落地docs/versions/目錄下按版本歸檔了 7.6.1、7.7.1、8.0.1、8.1.1、8.2.1、8.3.1、8.4.2、8.5.1、8.6.0、8.7.0、9.0.0、9.1.0 等版本的文檔說明每個 LTS/小版本都有獨立的文檔快照與之對應。支持矩陣各 LTS 版本當前處于什么階段下表為文檔給出的最新支持矩陣標注了各 LTS 主版本的支持階段、最新版本號與停止支持時間End of supportLTS releaseSupport stageLatest versionEnd of supportBazel 10Rolling以滾動發布頁為準N/ABazel 9Active9.2.0Dec 2028Bazel 8Maintenance8.8.0Dec 2027Bazel 7Maintenance7.7.1Dec 2026Bazel 6Deprecated6.6.0Dec 2025Bazel 5Deprecated5.4.1Jan 2025Bazel 4Deprecated4.2.4Jan 2024理解這張表時有兩點需要特別注意Latest 徽章不代表最新支持GitHub 倉庫上的 Latest 徽章始終指向語義版本號最高的那個版本即使某個舊版本的維護補丁發布得更晚徽章也不會指向它。因此判斷該用哪個版本應以上表支持階段為準而非倉庫徽章。版本跨度大時注意支持周期一個 LTS 版本在 Maintenance 階段停留 2 年后即進入 Deprecated 階段屆時官方不再提供任何支持用戶應遷移到更新的 LTS 版本。版本號規則語義化版本Semantic VersioningBazel 使用major.minor.patch的 Semantic Versioning 方案各段位的含義如下Major主版本包含與上一版本不向后兼容的特性。每個 major 版本就是一個 LTS 版本。Minor次版本包含向后兼容的缺陷修復和從主分支 back-port 回來的新特性。Patch補丁版本僅包含關鍵缺陷修復。Pre-release預發布在下一個主版本號后追加連字符和日期后綴來表示例如7.0.0-pre.20230502.1。文檔給出了一組直觀的示例同一次發布流程中四種類型版本號分別形如6.0.0Major、6.1.0Minor、6.1.2Patch、7.0.0-pre.20230502.1Pre-release。這套規則與倉庫發布腳本的實現互相印證release.sh 中的__do_release會讀取當前 release 分支與 release candidate 編號來生成 tag 名而滾動發布與 LTS 的命名/分支策略在腳本中也有明確區分詳見下文發布流程。支持階段Support Stages每個 Bazel 主版本都會經歷四個支持階段階段含義Rolling該主版本仍處于預發布階段Bazel 團隊從 HEAD 持續發布滾動版本。Active當前活躍的 LTS 版本。團隊會把重要特性與缺陷修復 back-port 到它的 minor 版本中。Maintenance處于維護模式的舊 LTS 版本。團隊只承諾 back-port 與安全、OS 兼容性相關的關鍵缺陷修復。Deprecated官方不再提供支持所有用戶都應遷移到更新的 Bazel LTS 版本。階段轉換的節奏是新 LTS 發布后立即進入 Active上一 LTS 進入 Maintenance在 Maintenance 停留 2 年后進入 Deprecated。發布節奏Release Cadence兩條軌道按不同的節奏發布滾動發布Rolling releases與 Google Blaze 發布協調大約每兩周從 HEAD 發布一次是下一個 Bazel LTS 版本的預覽可以攜帶不兼容變更。對于重大破壞性變更官方推薦使用--incompatible_*標志并遵循向后兼容策略。滾動發布的具體版本清單見滾動發布索引頁官方推薦使用 Bazelisk 來消費這些版本。LTS 發布LTS releasesMajor主版本預計約每 12 個月從 HEAD 切一次。新 LTS 一旦發布立即進入 Active 階段上一 LTS 進入 Maintenance。Minor次版本Active 軌道上的新 minor 版本預計每 2 個月發布一次。Patch補丁版本Active 與 Maintenance 階段的 LTS 按需發布 patch僅用于關鍵缺陷修復。發布流程與策略Release Procedure Policies滾動發布的流程滾動發布流程很直接大約每兩周創建一個新版本與 Google 內部 Blaze 發布保持同一基線。由于發布節奏快不會向滾動版本 back-port 任何變更。LTS 發布的完整流程LTS 發布遵循以下流程確定基線提交baseline commit新 major LTS基線為主分支的 HEADminor 或 patch 發布基線為當前最新版本的同一 LTS 發布分支的 HEAD。創建發布分支從基線提交創建名為release-version的分支。通過 PR 向發布分支 back-port 變更社區成員可在相關 issue/PR 上回復 bazel-io flag 將提交標記為潛在發布阻塞項release blocker由 Bazel 團隊分類并決定是否 back-port只有主分支上向后兼容的提交才能被 back-port為解決合并沖突所做的少量附帶修改可以接受。使用 Cherry-Pick Request Issue 請求 back-portBazel 維護者通過創建 cherry-pick 請求來申請將特定提交合入發布分支具體步驟為打開 cherry-pick 請求模板填寫請求詳情Title簡潔描述性標題、Commit ID(s)要 cherry-pick 的提交 ID多個用逗號分隔、Category請求類別、Reviewer(s)多個審閱者 ID 用逗號分隔設置 milestone在 Milestone 區域選擇對應的X.Y.Z發布阻塞項這會觸發 cherry-pick bot 為release-X.Y.Z分支處理你的請求提交 issue。cherry-pick bot 會處理請求并通知提交是否可被 cherry-pick如果 cherry-pick 時無合并沖突bot 會創建一個新的 PR該 PR 經 Bazel 團隊成員批準后提交被 cherry-pick 并合入發布分支。識別發布阻塞項并修復問題發布分支會與 postsubmit 和 downstream test pipeline 相同的測試套件在 Bazel CI 上運行團隊監控發布分支的測試結果并修復回歸。創建發布候選release candidate所有已知發布阻塞項解決后從發布分支創建新的 RC。RC 會在 bazel-discuss 郵件列表中公告團隊監控社區對該候選版本的 bug 報告若發現新的發布阻塞項回到上一步解決后重新創建 RC。首個 RC 創建后不允許再向發布分支添加新特性cherry-pick 僅限關鍵修復且請求者必須回答該變更為何關鍵、帶來什么收益、引入回歸的可能性有多大。將 RC 推送為正式發布若無進一步發布阻塞項則推送 RC 為官方版本patch 版本最后一個 RC 發布至少兩個工作日后推送major/minor 版本最后一個 RC 發布兩個工作日之后、且不早于首個 RC 發布一周之后推送僅在下一天是工作日的那天推送發布后在 bazel-discuss 公告團隊監控并處理社區對新手版的 bug 報告。源碼視角發布腳本如何落地這套流程倉庫中的 release.sh 正是上述流程的自動化實現關鍵函數與文檔步驟一一對應分支創建__create_releaserelease.sh接收發布名與基線提交創建形如release-namercn的分支branch_namerelease-${release_name}rc${force_rc}并調用__apply_cherry_picks把傳入的提交逐個 cherry-pick 到新分支——對應流程第 14 步。Cherry-pick 沖突處理__apply_cherry_picksrelease.sh在 cherry-pick 失敗時進入交互式 shell 提示維護者解決沖突可選擇git cherry-pick --abort或git cherry-pick --continue與文檔僅向后兼容提交可被 back-port、允許少量沖突修復的策略一致。發布與分支清理__do_releaserelease.sh先判斷is_rolling_release滾動發布只有rc1分支、沒有獨立的正式 release 分支非滾動發布則要求當前分支最后一個release-X.Y.ZrcN候選分支與正式分支release-X.Y.Z指向同一提交否則拒絕發布。隨后生成 release commit、打 tag、把 CHANGELOG.md 的更新合回 master 并推送。發布說明生成release 腳本還通過 relnotes.sh / relnotes.py 從提交歷史生成發布說明并在__create_release_commit中把說明寫入倉庫根目錄的 CHANGELOG.md保證每個版本都有可追溯的變更記錄。報告回歸與二分定位Report Regressions如果在新版本、發布候選甚至 HEAD 上發現回歸請在 GitHub 上提交 bug。文檔特別推薦使用Bazelisk 的 bisect 功能來定位罪魁提交culprit commit并把定位結果一并寫入 bug 報告。典型場景構建在 Bazel 6.1.0 上成功、卻在 6.2.0 的第二個 RC 上失敗可執行bazelisk --bisect6.1.0..release-6.2.0rc2 build //foo:bar補充要點可通過設置BAZELISK_SHUTDOWN或BAZELISK_CLEAN環境變量讓 Bazelisk 在執行對應 bazel 命令前先 shutdown/clean 構建狀態以便穩定復現問題使用 bisect 功能前請把 Bazelisk 升級到最新版本。更多 Bazelisk 用法可參考倉庫中的 bazelisk 安裝文檔。規則作者如何維護版本兼容對于規則rules作者若需要讓自己的 Starlark 規則同時兼容多個 Bazel 版本請參考 Rule Compatibility 頁面。其核心結論是規則對 Bazel 的兼容性斷裂有兩種典型場景依賴的特性在 HEAD 上被移除破壞與未來 LTS 的兼容或依賴的特性只在更新的 LTS 中可用破壞與當前/舊 LTS 的兼容追求可管理的遷移過程用戶不應被迫同時升級規則主版本與 Bazel 主版本最佳實踐包括規則自身遵循語義化版本HEAD 上的規則同時兼容最新 LTS 與 Bazel at HEAD利用--incompatible_*標志配合 向后兼容策略 平滑遷移。向后兼容破壞性變更如何落地與發布模型配套的向后兼容策略詳見 backward-compatibility.mdx要點如下破壞性變更推薦通過--incompatible_*標志引入每個--incompatible_*標志都對應一個解釋行為變化并提供遷移配方的 GitHub issue不兼容標志推薦 back-port 到最新 LTS 版本但默認不啟用讓用戶在下個 LTS 到來前完成遷移由--experimental_*標志守護的 API 與行為可隨時變化永遠不要在生產構建中使用--experimental_*或--incompatible_*標志。未帶--experimental_*的 API/行為一般視為穩定受支持特性包括 Starlark 語言與 API、隨 Bazel 分發的規則、Remote Execution API 與 Build Event Protocol 等 Bazel API以及命令行標志及其語義。小結Bazel 的發布模型是一套快節奏預覽 長周期穩定的雙軌體系滾動發布讓用戶每兩周就能嘗鮮下一個 LTS 的功能并提前適配破壞性變更LTS 發布則通過 Active/Maintenance/Deprecated 四階段為生產用戶提供最長數年的可預期支持。理解支持矩陣、語義化版本規則與release-version分支 RC 候選 cherry-pick bot 的發布流程是評估升級風險、參與社區 back-port 以及用 Bazelisk 定位回歸問題的前提。本文所有流程細節均來自倉庫中的 Release Model 文檔并由 release.sh 等發布腳本與docs/versions/下的版本化文檔目錄互相印證。【免費下載鏈接】bazela fast, scalable, multi-language and extensible build system項目地址: https://gitcode.com/GitHub_Trending/ba/bazel創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 Bazel 發布模型（Release Model）完全指南：Rolling 與 LTS 雙軌制、版本號規則與發布流程
Bazel 發布模型Release Model完全指南Rolling 與 LTS 雙軌制、版本號規則與發布流程【免費下載鏈接】bazela fast, scalable, multi-language and extensible build system項目地址: https://gitcode.com/GitHub_Trending/ba/bazel本文以 Bazel 官方 Release Model 文檔 為主體系統講解 Bazel 自 4.0 起采用的滾動發布Rolling 長期支持LTS雙軌發布模型包括支持矩陣與四個支持階段、major.minor.patch語義化版本規則、兩類發布軌道各自的節奏與完整發布流程以及如何用 Bazelisk 對回歸問題做二分定位。讀完本文你將能夠看懂 Bazel 任意版本號背后的含義、判斷某個版本當前處于什么支持狀態并理解從基線提交到正式發布的全過程及其中的 cherry-pick 與 release candidate 機制。雙軌發布模型Rolling 與 LTSBazel 4.0 及更高版本提供兩條發布軌道release track滾動發布Rolling releases從主分支HEAD直接發布每兩周左右一個版本是下一個 LTS 版本的預覽。滾動發布可以與 Google 內部的 Blaze 發布保持同一基線baseline。長期支持發布LTS releases每約 12 個月從 HEAD 切出一個新的主版本成為當期的 Active 版本并在隨后數年內依次經歷 Maintenance、Deprecated 階段為用戶提供可預期的長期支持窗口。從倉庫結構可以佐證這套模型的落地docs/versions/目錄下按版本歸檔了 7.6.1、7.7.1、8.0.1、8.1.1、8.2.1、8.3.1、8.4.2、8.5.1、8.6.0、8.7.0、9.0.0、9.1.0 等版本的文檔說明每個 LTS/小版本都有獨立的文檔快照與之對應。支持矩陣各 LTS 版本當前處于什么階段下表為文檔給出的最新支持矩陣標注了各 LTS 主版本的支持階段、最新版本號與停止支持時間End of supportLTS releaseSupport stageLatest versionEnd of supportBazel 10Rolling以滾動發布頁為準N/ABazel 9Active9.2.0Dec 2028Bazel 8Maintenance8.8.0Dec 2027Bazel 7Maintenance7.7.1Dec 2026Bazel 6Deprecated6.6.0Dec 2025Bazel 5Deprecated5.4.1Jan 2025Bazel 4Deprecated4.2.4Jan 2024理解這張表時有兩點需要特別注意Latest 徽章不代表最新支持GitHub 倉庫上的 Latest 徽章始終指向語義版本號最高的那個版本即使某個舊版本的維護補丁發布得更晚徽章也不會指向它。因此判斷該用哪個版本應以上表支持階段為準而非倉庫徽章。版本跨度大時注意支持周期一個 LTS 版本在 Maintenance 階段停留 2 年后即進入 Deprecated 階段屆時官方不再提供任何支持用戶應遷移到更新的 LTS 版本。版本號規則語義化版本Semantic VersioningBazel 使用major.minor.patch的 Semantic Versioning 方案各段位的含義如下Major主版本包含與上一版本不向后兼容的特性。每個 major 版本就是一個 LTS 版本。Minor次版本包含向后兼容的缺陷修復和從主分支 back-port 回來的新特性。Patch補丁版本僅包含關鍵缺陷修復。Pre-release預發布在下一個主版本號后追加連字符和日期后綴來表示例如7.0.0-pre.20230502.1。文檔給出了一組直觀的示例同一次發布流程中四種類型版本號分別形如6.0.0Major、6.1.0Minor、6.1.2Patch、7.0.0-pre.20230502.1Pre-release。這套規則與倉庫發布腳本的實現互相印證release.sh 中的__do_release會讀取當前 release 分支與 release candidate 編號來生成 tag 名而滾動發布與 LTS 的命名/分支策略在腳本中也有明確區分詳見下文發布流程。支持階段Support Stages每個 Bazel 主版本都會經歷四個支持階段階段含義Rolling該主版本仍處于預發布階段Bazel 團隊從 HEAD 持續發布滾動版本。Active當前活躍的 LTS 版本。團隊會把重要特性與缺陷修復 back-port 到它的 minor 版本中。Maintenance處于維護模式的舊 LTS 版本。團隊只承諾 back-port 與安全、OS 兼容性相關的關鍵缺陷修復。Deprecated官方不再提供支持所有用戶都應遷移到更新的 Bazel LTS 版本。階段轉換的節奏是新 LTS 發布后立即進入 Active上一 LTS 進入 Maintenance在 Maintenance 停留 2 年后進入 Deprecated。發布節奏Release Cadence兩條軌道按不同的節奏發布滾動發布Rolling releases與 Google Blaze 發布協調大約每兩周從 HEAD 發布一次是下一個 Bazel LTS 版本的預覽可以攜帶不兼容變更。對于重大破壞性變更官方推薦使用--incompatible_*標志并遵循向后兼容策略。滾動發布的具體版本清單見滾動發布索引頁官方推薦使用 Bazelisk 來消費這些版本。LTS 發布LTS releasesMajor主版本預計約每 12 個月從 HEAD 切一次。新 LTS 一旦發布立即進入 Active 階段上一 LTS 進入 Maintenance。Minor次版本Active 軌道上的新 minor 版本預計每 2 個月發布一次。Patch補丁版本Active 與 Maintenance 階段的 LTS 按需發布 patch僅用于關鍵缺陷修復。發布流程與策略Release Procedure Policies滾動發布的流程滾動發布流程很直接大約每兩周創建一個新版本與 Google 內部 Blaze 發布保持同一基線。由于發布節奏快不會向滾動版本 back-port 任何變更。LTS 發布的完整流程LTS 發布遵循以下流程確定基線提交baseline commit新 major LTS基線為主分支的 HEADminor 或 patch 發布基線為當前最新版本的同一 LTS 發布分支的 HEAD。創建發布分支從基線提交創建名為release-version的分支。通過 PR 向發布分支 back-port 變更社區成員可在相關 issue/PR 上回復 bazel-io flag 將提交標記為潛在發布阻塞項release blocker由 Bazel 團隊分類并決定是否 back-port只有主分支上向后兼容的提交才能被 back-port為解決合并沖突所做的少量附帶修改可以接受。使用 Cherry-Pick Request Issue 請求 back-portBazel 維護者通過創建 cherry-pick 請求來申請將特定提交合入發布分支具體步驟為打開 cherry-pick 請求模板填寫請求詳情Title簡潔描述性標題、Commit ID(s)要 cherry-pick 的提交 ID多個用逗號分隔、Category請求類別、Reviewer(s)多個審閱者 ID 用逗號分隔設置 milestone在 Milestone 區域選擇對應的X.Y.Z發布阻塞項這會觸發 cherry-pick bot 為release-X.Y.Z分支處理你的請求提交 issue。cherry-pick bot 會處理請求并通知提交是否可被 cherry-pick如果 cherry-pick 時無合并沖突bot 會創建一個新的 PR該 PR 經 Bazel 團隊成員批準后提交被 cherry-pick 并合入發布分支。識別發布阻塞項并修復問題發布分支會與 postsubmit 和 downstream test pipeline 相同的測試套件在 Bazel CI 上運行團隊監控發布分支的測試結果并修復回歸。創建發布候選release candidate所有已知發布阻塞項解決后從發布分支創建新的 RC。RC 會在 bazel-discuss 郵件列表中公告團隊監控社區對該候選版本的 bug 報告若發現新的發布阻塞項回到上一步解決后重新創建 RC。首個 RC 創建后不允許再向發布分支添加新特性cherry-pick 僅限關鍵修復且請求者必須回答該變更為何關鍵、帶來什么收益、引入回歸的可能性有多大。將 RC 推送為正式發布若無進一步發布阻塞項則推送 RC 為官方版本patch 版本最后一個 RC 發布至少兩個工作日后推送major/minor 版本最后一個 RC 發布兩個工作日之后、且不早于首個 RC 發布一周之后推送僅在下一天是工作日的那天推送發布后在 bazel-discuss 公告團隊監控并處理社區對新手版的 bug 報告。源碼視角發布腳本如何落地這套流程倉庫中的 release.sh 正是上述流程的自動化實現關鍵函數與文檔步驟一一對應分支創建__create_releaserelease.sh接收發布名與基線提交創建形如release-namercn的分支branch_namerelease-${release_name}rc${force_rc}并調用__apply_cherry_picks把傳入的提交逐個 cherry-pick 到新分支——對應流程第 14 步。Cherry-pick 沖突處理__apply_cherry_picksrelease.sh在 cherry-pick 失敗時進入交互式 shell 提示維護者解決沖突可選擇git cherry-pick --abort或git cherry-pick --continue與文檔僅向后兼容提交可被 back-port、允許少量沖突修復的策略一致。發布與分支清理__do_releaserelease.sh先判斷is_rolling_release滾動發布只有rc1分支、沒有獨立的正式 release 分支非滾動發布則要求當前分支最后一個release-X.Y.ZrcN候選分支與正式分支release-X.Y.Z指向同一提交否則拒絕發布。隨后生成 release commit、打 tag、把 CHANGELOG.md 的更新合回 master 并推送。發布說明生成release 腳本還通過 relnotes.sh / relnotes.py 從提交歷史生成發布說明并在__create_release_commit中把說明寫入倉庫根目錄的 CHANGELOG.md保證每個版本都有可追溯的變更記錄。報告回歸與二分定位Report Regressions如果在新版本、發布候選甚至 HEAD 上發現回歸請在 GitHub 上提交 bug。文檔特別推薦使用Bazelisk 的 bisect 功能來定位罪魁提交culprit commit并把定位結果一并寫入 bug 報告。典型場景構建在 Bazel 6.1.0 上成功、卻在 6.2.0 的第二個 RC 上失敗可執行bazelisk --bisect6.1.0..release-6.2.0rc2 build //foo:bar補充要點可通過設置BAZELISK_SHUTDOWN或BAZELISK_CLEAN環境變量讓 Bazelisk 在執行對應 bazel 命令前先 shutdown/clean 構建狀態以便穩定復現問題使用 bisect 功能前請把 Bazelisk 升級到最新版本。更多 Bazelisk 用法可參考倉庫中的 bazelisk 安裝文檔。規則作者如何維護版本兼容對于規則rules作者若需要讓自己的 Starlark 規則同時兼容多個 Bazel 版本請參考 Rule Compatibility 頁面。其核心結論是規則對 Bazel 的兼容性斷裂有兩種典型場景依賴的特性在 HEAD 上被移除破壞與未來 LTS 的兼容或依賴的特性只在更新的 LTS 中可用破壞與當前/舊 LTS 的兼容追求可管理的遷移過程用戶不應被迫同時升級規則主版本與 Bazel 主版本最佳實踐包括規則自身遵循語義化版本HEAD 上的規則同時兼容最新 LTS 與 Bazel at HEAD利用--incompatible_*標志配合 向后兼容策略 平滑遷移。向后兼容破壞性變更如何落地與發布模型配套的向后兼容策略詳見 backward-compatibility.mdx要點如下破壞性變更推薦通過--incompatible_*標志引入每個--incompatible_*標志都對應一個解釋行為變化并提供遷移配方的 GitHub issue不兼容標志推薦 back-port 到最新 LTS 版本但默認不啟用讓用戶在下個 LTS 到來前完成遷移由--experimental_*標志守護的 API 與行為可隨時變化永遠不要在生產構建中使用--experimental_*或--incompatible_*標志。未帶--experimental_*的 API/行為一般視為穩定受支持特性包括 Starlark 語言與 API、隨 Bazel 分發的規則、Remote Execution API 與 Build Event Protocol 等 Bazel API以及命令行標志及其語義。小結Bazel 的發布模型是一套快節奏預覽 長周期穩定的雙軌體系滾動發布讓用戶每兩周就能嘗鮮下一個 LTS 的功能并提前適配破壞性變更LTS 發布則通過 Active/Maintenance/Deprecated 四階段為生產用戶提供最長數年的可預期支持。理解支持矩陣、語義化版本規則與release-version分支 RC 候選 cherry-pick bot 的發布流程是評估升級風險、參與社區 back-port 以及用 Bazelisk 定位回歸問題的前提。本文所有流程細節均來自倉庫中的 Release Model 文檔并由 release.sh 等發布腳本與docs/versions/下的版本化文檔目錄互相印證。【免費下載鏈接】bazela fast, scalable, multi-language and extensible build system項目地址: https://gitcode.com/GitHub_Trending/ba/bazel創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考