File Transfer 開源 P2P 傳檔：取件碼把檔案直送對方瀏覽器

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

打開任何一套點對點傳檔工具的介紹，幾乎都會看到同一句話：檔案不經過伺服器。這句話在網路環境配合的時候是真的，問題是你永遠不知道自己的網路環境配不配合，而多數工具不會告訴你它連不上之後發生了什麼事。開源專案 File Transfer（GitHub 上叫 file-transfer-go）值得看的地方就在這裡：它把連不上之後的出路直接寫進了程式，連多久算失敗、失敗後走哪條路、走替代路徑時介面要不要提示，全都有明確答案。

先交代它的基本盤。這是一套 MIT 授權的開源傳檔服務，作者 MatrixSeven 用 Go 寫後端、Next.js 寫前端，截至 2026 年 8 月 27 日在 GitHub 累積 5,104 顆星、650 次 fork，最新版本 v1.1.0 於 2026 年 6 月 8 日發布，Docker 映像檔被拉取約 9.8 萬次。專案從 2025 年 7 月底開始開發，一年內出了 9 個正式版，每個版本都附帶跨平台執行檔與校驗檔。功能除了檔案傳輸，還有文字訊息、桌面共享、目錄同步與斷點續傳，全部圍繞一個共用概念：六位取件碼。你在發送端開一間房，把取件碼或 QR 圖給對方，對方輸入碼就進房，兩邊的瀏覽器直接互連。

實際開一間房：取件碼、分享連結與兩端的連線燈號

我在官方示範站 transfer.52python.cn 實際跑了一輪發送與接收。流程比想像中短：切到檔案傳輸分頁，選好檔案，按發送，畫面跳出「生成取件碼」的按鈕，按下去房間就建立了。取件碼是六位英數字，我這輪拿到的是 NHHXH2；稍微留意格式會發現它不是純數字，字元集刻意排除了數字 0 和字母 O，唸給同事聽的時候要連字母一起唸。房間建立後畫面同步給出兩種分享方式：直接複製取件碼，或掃 QR 圖，QR 對應的是一條 /s/ 開頭的短網址，手機掃了就能進接收畫面，省掉手動敲碼的力氣。

Pin

接收端的進房設計也有一個小細節：取件碼輸入框旁邊掛著 0/6 的位數計數器，輸滿六位才能按開始接收，輸入體驗是照著「口頭唸碼、逐位輸入」的場景做的。輸入之前如果想確認房間還在，後端也開了一組查詢介面，帶著取件碼去問，會回傳房間是否存在、建立時間，以及發送端與接收端各自是否連著線；拿一組不存在的碼去查，回的是房間不存在或已過期。對接收方來說，先查再進可以少踩一次空房間。

介面上最值得停下來看的是右上角的兩顆燈號，一顆標 WS，一顆標 RTC，分別代表 WebSocket 信令連線與 WebRTC 資料通道。發送端剛開好房時是 WS 已連接、RTC 未連接的狀態，代表房間在伺服器上掛了號，兩邊還沒牽上線；接收端在另一個瀏覽器輸入取件碼加入後，兩顆燈轉成雙綠，狀態文字換成 P2P 連線成功，檔案清單裡我的測試檔 heist_ft_test.txt 與 16.41 KB 的大小也同步出現了。把信令與資料通道分開顯示是個聰明的設計，使用者能一眼看出「我連上了房間」與「我連上了對方」是兩件事。

Pin

分頁列上還有幾個與檔案傳輸並列的模式，都是同一套取件碼邏輯的延伸：文字訊息把一段文字變成六位碼分享；共享桌面把畫面串流給進房的對方；另外有一個微信群分頁放社群入口，以及一個中繼設定分頁，把降級用的中繼選項攤在介面上，而不是藏在說明文件裡。功能表本身會說話：這套工具想照顧的情境比純傳檔更寬，比較接近一個以取件碼為中心的輕量連線房間。

這輪實測有一條邊界要說清楚：我在同一部機器上用兩個瀏覽器分飾發送與接收兩端，完成到連線建立與檔案清單同步，檔案本體的傳輸與保存動作沒有在這個測試環境裡走完，所以關於大檔速度與長時間穩定度，這篇不做任何結論。跨網路的 NAT 穿透情境同樣超出這輪測試範圍，下一段用原始碼來補這塊拼圖。

直連是最好的情況，不是它給你的承諾

README 對安全性的宣稱寫得很滿：端到端加密、資料不經過伺服器、伺服器不存檔。對照原始碼看，這些話要拆成兩半來讀。前端的連線核心 useWebRTCConnectionCore.ts 開頭註解就寫明白：支援 P2P 到 WS 中繼的自動降級。整段邏輯由三個計時器驅動：

• ICE 連線斷開後 8 秒沒有恢復，啟動降級。
• P2P 連線 10 秒內沒有建立，啟動降級。
• 對方進房後 15 秒對等連線仍未成立，啟動降級。

降級的目標是後端的另一組 WebSocket 端點，資料改由伺服器在兩端之間轉發。觸發時限都在十幾秒內，使用者的體感就是「等了一下子，然後通了」，不會察覺路徑已經換過，除非介面提示出現。

轉發這一段的實作在 relay_service.go，設計上有兩個對使用者有意義的特點。其一是只轉發不落碟：中繼房間把雙方的連線放在記憶體裡，單則訊息上限 10MB 分片流過，任一方斷線、房間清空就刪除，整個服務沒有把檔案寫入磁碟的路徑，所以「伺服器不存檔」這句宣稱在中繼模式下也成立。其二是內容可見度：直連路徑的加密由 WebRTC 的 DTLS 負責，中繼路徑走的卻是 WebSocket，從程式結構看，轉發中的內容對伺服器而言是接觸得到的，專案文件也沒有對中繼路徑提供端到端加密的說法。換句話說，隱私承諾的強度取決於你落在哪個模式，而模式取決於網路環境。

決定落點的關鍵配置是 ICE 伺服器清單。原始碼的預設值給了五顆 STUN 伺服器，分別來自 easyvoip、小米路由器的 miwifi、兩顆 Google 與一顆 Twilio，沒有任何一顆 TURN。沒有 TURN 代表遇到對稱 NAT 或封鎖 UDP 的公司防火牆時，直連大概率打不通。設定頁提供了自行新增 STUN 與 TURN 的介面，設定存在瀏覽器的 localStorage，對網路環境複雜的人來說，自備一顆 TURN 伺服器是讓直連成立的最有效手段。瀏覽器完全不支援 WebRTC 的情況也有處理：程式裡有一個專屬的提示視窗，會偵測當前瀏覽器狀態並引導換用支援的瀏覽器。想深入理解 STUN 與 TURN 在瀏覽器直連裡的角色，可以搭配我們先前對 FileSync 的三段式工程拆解一起看，那篇把打洞與中繼的原理講得更完整。

2026 年 3 月 23 日的那次提交還補上了一個細節：介面會在中繼模式啟用時給使用者提示。這把降級從黑箱變成產品事實，也是我認為這套工具最值得肯定的地方。多數同類工具要嘛連不上就失敗，要嘛默默切到雲端上傳，把「現在我到底走在哪條路上」留給使用者猜。

原始碼裡的兩個落差：房間壽命與取件碼的亂數

翻原始碼的過程裡有兩個發現，都會直接影響使用方式。先是房間壽命的前後端不一致。接收頁的提示文字告訴你取件碼有效期為 24 小時，但後端 webrtc_service.go 在建立房間時設定的到期時間是 1 小時，而且整個服務只有這一處寫入，沒有任何延長壽命的邏輯，背景程序每 5 分鐘清理一次過期房間。兩邊對不上時，保守的做法是把 1 小時當基準：開了房就盡快把碼交出去、把檔案傳完，別把它當隔天還能領的保管箱。真需要非同步保管，站上介紹過的 取文件那類伺服器端保管櫃，或 AuraShare 的限時連結，才是對的形態。

另一個發現是取件碼的產生方式。generatePickupCode 用的是 Go 的 math/rand，種子取當下時間戳，屬於一般用途的偽隨機，密碼學等級的 crypto/rand 並沒有用在這裡。34 個字元取 6 位，組合空間約 15.4 億，日常把碼唸給同事、貼到群組的場景夠用，線上猜碼也要先對上房間存在且剛好開著房的時段。但如果你的檔案敏感到威脅模型裡有「有人會嘗試猜碼」這一條，這組碼不該被當成高強度密碼看待，更合理的組合是自架實例加私有網路，或改用 DropLock 那類以端到端加密為核心設計的工具。

同一個誠實軸上還有個小發現值得記錄：官方示範站的首頁載入了兩個分析元件，一個是掛在 track.icats.club 的統計腳本，另一個是 Microsoft Clarity 的工作階段分析。這與檔案傳輸本體是兩層事，傳輸路徑照樣照上述規則走，但示範站本身對訪客有站長端的分析行為。自架版本沒有這些腳本，要與不要由你自己決定。

自架一套，把信任對象換成自己

說了這麼多邊界，這套工具最有份量的答案其實是把伺服器端整包搬回家。它的後端是單一 Go 執行檔，靜態前端直接內嵌，官方提供三種部署路徑：Docker Compose 一行起、直接拉映像檔跑在 8080 埠，或用建置腳本在本機產出單檔執行檔，映像檔同時提供 amd64 與 arm64 架構，放在 NAS 或小 VPS 上都行。最短的路徑長這樣：

docker run -d -p 8080:8080 --name file-transfer-go matrixseven/file-transfer-go:latest

可調的環境變數只有 NODE_ENV、PORT 與 GO_BACKEND_URL 三個，沒有資料庫、不需要任何外部服務，這一點從 Go 後端的依賴清單也看得出來，路由用 chi、WebSocket 用 gorilla/websocket，除此之外都是標準庫。需要幫助文件時，站上附了一個教學頁，倉庫裡另外留了架構說明與協定分析兩份長文件，對想讀懂內部運作的人是加分項。

自架的意義要對照前面的降級設計才完整：信令 WebSocket 與中繼端點都落在你自己跑的執行檔裡，就算兩端直連失敗、資料必須經過伺服器轉發，經過的也是你的機器，不是作者或其他陌生人的。對端到端有嚴格要求的人，這才是把不確定性收斂掉的根本做法。以輕量網頁工具的標準看，這套系統的可攜性算乾淨的。

適合誰，誰先繞道

綜合這輪實測與原始碼查證，File Transfer 適合的人有三種：常常要在自己的裝置之間或小圈圈裡丟大檔、不想登入任何帳號的人；願意花十分鐘用 Docker 自架、把信令與中繼收回自己手上的技術使用者；以及需要臨時共享桌面畫面、順手講個語音，又不想裝會議軟體的人。桌面共享與語音通話這兩塊，我在原始碼裡確認了對應元件存在，這輪沒有實測，能力細節以官方說明為準。

先繞道的名單如下。需要非同步交付、對方沒有同時連線也要能領檔的人，請走向伺服器保管櫃形態的工具；傳輸內容機密到連伺服器轉發都不能接受、又無力自架的人，端到端加密的專用工具更對題；要的是長期協作空間而非一次性傳檔的人，奶牛快傳那類服務或雲端硬碟反而省事。目錄同步與斷點續傳是說明文件上列出的進階功能，設定的情境是兩台機器之間持續搬整個資料夾，這條路線能不能應付你的日常同步量，建議先拿小目錄試一輪再上真正的資料。

這也是整篇最想留下的一個判斷方式：面對任何標榜 P2P 的工具，先問它連不上時走哪裡、走替代路徑時使用者知不知道，這兩題的答案，比首頁任何一句安全宣稱都更能告訴你它是什麼等級的東西。File Transfer 在這兩題上的答案是三個計時器加一個介面提示，外加一套可以搬回家的伺服器端，在免費開源傳檔工具裡，這個誠實度不算常見。想試的人，直接開官方示範站傳一個小檔感受流程；想認真用的人，花十分鐘把它架在自己的機器上，問題就從「要不要信任作者」變成「要不要信任自己」。