Facebook Thrift：Apache Thrift 的演化分支
專案速覽：Facebook 維護的 Apache Thrift 分支，包含重構後的 C++ 伺服器，並支援 C++、Python、Hack、Java 等主流語言。
秒懂
- 它是什麼？
- 一個序列化和 RPC 框架，擁有重寫的編譯器和新的非同步 C++ 伺服器，採用 Apache 2.0 授權。
- 適合誰用？
- 適合需要評估 facebook/fbthrift 檔案所述能力的讀者，不適合把本文當成完整效能或安全測試報告。先依 README 的實際命令與檔案入口試跑，記下版本、輸入、輸出與錯誤，再決定是否納入正式流程。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 C++（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
演化分支，而非分發版本
README 開頭澄清 Facebook Thrift 不是 Apache Thrift 的分發版本。它是 Facebook 於 2014 年 2 月重新發佈到開源社群的一個內部分支。最初與 Apache Thrift 緊密跟蹤，現在該專案已經向新的方向發展：編譯器從頭重寫，新實作具備完全非同步的 Thrift 伺服器。倉庫描述也指出它包含一個新的 C++ 伺服器。README 提供了關於建構和開源 fbthrift 的 Facebook Code 部落格文章連結作為歷史背景。
以 facebook/fbthrift 為中心閱讀素材，可確認的範圍是 README、倉庫欄位與發布紀錄；未在這些內容出現的效能、相容性或安全承諾不應自行補上。這種界線讓文章能區分作者明說的能力與仍待本地確認的假設。 本段專看第 1 個核對面向：把 facebook/fbthrift 的名稱、版本與實際輸出放在同一筆紀錄中，才能在再次執行時辨識差異。
採用前可從 facebook/fbthrift 的 README 指定入口開始，並把輸入、輸出和錯誤訊息留下來。若檔案列出命令、設定檔或資料格式，應逐項對應；若檔案未說明某個環節，這就是本專案目前的未知，不宜用其他工具的經驗代替。 對 facebook/fbthrift 而言，這個觀察點必須連同本段列出的專案名一起閱讀，不能抽離成一般工具的保證。
針對 facebook/fbthrift 的第 1 項紀錄，還要檢查命令是否在預期目錄執行、輸入格式是否與 README 相同、輸出是否可被下一步工具讀取，以及失敗時是否留下足夠錯誤訊息。這些觀察能把檔案敘述轉成可追蹤的工程紀錄，也能指出哪些結果只是本機環境造成。
程式碼產生、序列化和 RPC
Thrift 被描述為三個主要部分。程式碼產生器產生可序列化的資料結構以及不同語言的用戶端/伺服器樁。序列化框架提供跨語言序列化產生結構的協定。RPC 框架在用戶端和伺服器之間對訊息進行幀化，並在接收時呼叫應用定義的函式。README 稱 Thrift 支援所有主要語言，並大力支援 C++、Python、Hack 和 Java。Facebook 的大多數服務使用 Thrift 進行 RPC，一些儲存系統使用 Thrift 序列化磁碟上的記錄。
實際核對時應把 main 分支與最近可見的發布標籤分開記錄。素材列出的最新標籤是 v2020.08.24.00，其發布頁可對照變更內容。 文章只把這些資料當作時間點，不將 star 或 issue 數量當成品質證明。 本段專看第 2 個核對面向：把 facebook/fbthrift 的名稱、版本與實際輸出放在同一筆紀錄中，才能在再次執行時辨識差異。
維護者需要特別檢查 facebook/fbthrift 的依賴邊界與授權條件。素材標示的授權為 Apache-2.0；它只說明分發與修改時要閱讀的法律條件，不能代替第三方依賴盤點、組織政策審查或部署環境的風險評估。 對 facebook/fbthrift 而言，這個觀察點必須連同本段列出的專案名一起閱讀，不能抽離成一般工具的保證。
針對 facebook/fbthrift 的第 2 項紀錄，還要檢查命令是否在預期目錄執行、輸入格式是否與 README 相同、輸出是否可被下一步工具讀取，以及失敗時是否留下足夠錯誤訊息。這些觀察能把檔案敘述轉成可追蹤的工程紀錄，也能指出哪些結果只是本機環境造成。
四個設計目標
README 列出了四個關鍵目標。易用性：Thrift 處理序列化和 RPC 的樣板程式碼，讓開發者專注於模式和介面。跨語言支援：例如 Python 用戶端與 C++ 伺服器通訊。效能：Thrift 結構和服務實現快速序列化和反序列化，其 RPC 協定和框架以效能為設計特性。向後相容性：允許在可序列化型別中新增和刪除欄位，同時保持向前和向後相容。
採用前可從 facebook/fbthrift 的 README 指定入口開始，並把輸入、輸出和錯誤訊息留下來。若檔案列出命令、設定檔或資料格式，應逐項對應；若檔案未說明某個環節，這就是本專案目前的未知，不宜用其他工具的經驗代替。 本段專看第 3 個核對面向：把 facebook/fbthrift 的名稱、版本與實際輸出放在同一筆紀錄中，才能在再次執行時辨識差異。
這篇文章的判斷落在 facebook/fbthrift 自身的工作流程：先用檔案中的最小入口得到可觀察結果，再以 README、版本標籤和原始碼中的實際路徑核對差異。測試若只停留在首頁、範例截圖或宣傳描述，無法證明你的輸入與部署方式也成立。 對 facebook/fbthrift 而言，這個觀察點必須連同本段列出的專案名一起閱讀，不能抽離成一般工具的保證。
針對 facebook/fbthrift 的第 3 項紀錄，還要檢查命令是否在預期目錄執行、輸入格式是否與 README 相同、輸出是否可被下一步工具讀取，以及失敗時是否留下足夠錯誤訊息。這些觀察能把檔案敘述轉成可追蹤的工程紀錄，也能指出哪些結果只是本機環境造成。
使用 getdeps.py 從原始碼建構
建構說明依賴一個名為 getdeps.py 的指令碼。在 Linux 或安裝了 Homebrew 的 macOS 上，克隆後可以執行 `./build/fbcode_builder/getdeps.py install-system-deps --recursive fbthrift` 安裝系統依賴。在其他平台上，getdeps.py 會下載並建構大多數依賴。建構命令是 `./build/fbcode_builder/getdeps.py --allow-system-packages build fbthrift`。輸出包括 `installed/fbthrift/bin/thrift1`（編譯器）和 `installed/fbthrift/lib/libthriftcpp2.a`（用戶端/伺服器庫）。依賴涵蓋系統套件（Boost、CMake、OpenSSL、PThreads、Python、Zlib）、外部庫（fmt、GFlags、GLog、GTest 和 GMock）以及 Facebook 專案（Fizz、Folly、Wangle、Zstd）。編譯器本身只依賴 Boost、CMake 和 {fmt}。
維護者需要特別檢查 facebook/fbthrift 的依賴邊界與授權條件。素材標示的授權為 Apache-2.0；它只說明分發與修改時要閱讀的法律條件，不能代替第三方依賴盤點、組織政策審查或部署環境的風險評估。 本段專看第 4 個核對面向：把 facebook/fbthrift 的名稱、版本與實際輸出放在同一筆紀錄中，才能在再次執行時辨識差異。
當 facebook/fbthrift 進入團隊流程後，應把本次核對的版本、命令、設定和輸出連同失敗案例保存。素材沒有提供的部分標成未說明，等實際維護時由負責人補上證據；這比把推測寫成固定功能更能支撐後續升級決定。 對 facebook/fbthrift 而言，這個觀察點必須連同本段列出的專案名一起閱讀，不能抽離成一般工具的保證。
針對 facebook/fbthrift 的第 4 項紀錄，還要檢查命令是否在預期目錄執行、輸入格式是否與 README 相同、輸出是否可被下一步工具讀取，以及失敗時是否留下足夠錯誤訊息。這些觀察能把檔案敘述轉成可追蹤的工程紀錄，也能指出哪些結果只是本機環境造成。
透過 CMake 整合產生的程式碼
對於使用 CMake 的專案，README 說應包含 `ThriftLibrary.cmake`，然後使用 `thrift_library` 巨集。該巨集接受檔案名稱、服務、語言、選項、檔案路徑和輸出路徑等引數。它會產生名為 `file_name-<language>` 的庫；例如，`Test.thrift` 作為 cpp2 編譯會產生 `Test-cpp2`。該庫應作為依賴新增到任何包含產生程式碼的來源檔案或標頭檔。README 還提到一個 CMake 選項 `THRIFT_COMPILER_ONLY` 用於僅建構編譯器，以及 `enable_tests` 選項。
這篇文章的判斷落在 facebook/fbthrift 自身的工作流程：先用檔案中的最小入口得到可觀察結果，再以 README、版本標籤和原始碼中的實際路徑核對差異。測試若只停留在首頁、範例截圖或宣傳描述，無法證明你的輸入與部署方式也成立。 本段專看第 5 個核對面向：把 facebook/fbthrift 的名稱、版本與實際輸出放在同一筆紀錄中，才能在再次執行時辨識差異。
以 facebook/fbthrift 為中心閱讀素材，可確認的範圍是 README、倉庫欄位與發布紀錄；未在這些內容出現的效能、相容性或安全承諾不應自行補上。這種界線讓文章能區分作者明說的能力與仍待本地確認的假設。 對 facebook/fbthrift 而言，這個觀察點必須連同本段列出的專案名一起閱讀，不能抽離成一般工具的保證。
針對 facebook/fbthrift 的第 5 項紀錄，還要檢查命令是否在預期目錄執行、輸入格式是否與 README 相同、輸出是否可被下一步工具讀取，以及失敗時是否留下足夠錯誤訊息。這些觀察能把檔案敘述轉成可追蹤的工程紀錄，也能指出哪些結果只是本機環境造成。
Python wheel、靜態反射和伺服器指標
README 描述了一個 thrift-python 建構，它產生一個可在 Python 3.8+ 環境中安裝的 wheel。它給出了使用 Docker BuildKit、傳統 Docker 和 Podman 進行容器建構的命令，以及使用 apt 和 conda 進行非容器建構的命令。建構後，wheel 可以用 pip 安裝，並透過一行 Python 匯入進行驗證。對於 C++ 靜態反射，README 指向 `thrift/lib/cpp2/reflection/` 中的單獨 README。對於伺服器指標，C++ 伺服器支援一個觀察者 API，在特定執行點安裝回呼，並可透過 fb303 介面暴露指標。
當 facebook/fbthrift 進入團隊流程後，應把本次核對的版本、命令、設定和輸出連同失敗案例保存。素材沒有提供的部分標成未說明，等實際維護時由負責人補上證據；這比把推測寫成固定功能更能支撐後續升級決定。 本段專看第 6 個核對面向：把 facebook/fbthrift 的名稱、版本與實際輸出放在同一筆紀錄中，才能在再次執行時辨識差異。
實際核對時應把 main 分支與最近可見的發布標籤分開記錄。素材列出的最新標籤是 v2020.08.24.00，其發布頁可對照變更內容。 文章只把這些資料當作時間點，不將 star 或 issue 數量當成品質證明。 對 facebook/fbthrift 而言，這個觀察點必須連同本段列出的專案名一起閱讀，不能抽離成一般工具的保證。
針對 facebook/fbthrift 的第 6 項紀錄，還要檢查命令是否在預期目錄執行、輸入格式是否與 README 相同、輸出是否可被下一步工具讀取，以及失敗時是否留下足夠錯誤訊息。這些觀察能把檔案敘述轉成可追蹤的工程紀錄，也能指出哪些結果只是本機環境造成。
編輯結論
適合需要評估 facebook/fbthrift 檔案所述能力的讀者，不適合把本文當成完整效能或安全測試報告。先依 README 的實際命令與檔案入口試跑，記下版本、輸入、輸出與錯誤，再決定是否納入正式流程。對 facebook/fbthrift 未說明的相容性、資源消耗與部署限製，應保留為待確認項目，不能由文章推定。
社群筆記