PrintRelay 免登入掃碼傳檔：手機送檔到公用電腦的臨時通道，適合什麼、不適合什麼

Facebook Line Messenger Telegram

借別人的電腦印一份 PDF，最常卡在「怎麼把手機裡的檔案送過去」這一步。AirDrop 要同一個 Wi-Fi，雲端硬碟要登入，印完還怕忘了退出帳號。PrintRelay 接手的就是這個環節：電腦打開網頁、手機掃碼，檔案就送過去，全程不必登入任何帳號。它跑在 Streamlit 雲端上，是個免費網頁工具，定位是「臨時跨端傳檔」，目的是把公用電腦上的帳號殘留風險壓到最低。實際打開它，第一眼看到的其實是 app 正在休眠的提示。

重點先看：PrintRelay 用掃碼把手機檔案送到電腦，免登入、免同一區網，適合在公用電腦上臨時印 PDF、圖片這類小檔案；它跑在 Streamlit Community Cloud 免費版上，會休眠、冷啟動慢，檔案走伺服器中繼而非點對點，「加密」與「傳完即清」是頁面提示與設計宣稱，機制本身沒有公開文件背書，別拿來傳敏感資料。

閒置會休眠，冷啟動要等

實際開 printrelay.streamlit.app，映入眼簾的是一行「This app has gone to sleep due to inactivity」，要你按一下把 app 喚醒。按下去後，頁面標題變成「Document Relay · Streamlit」，但接下來約兩分鐘，畫面停在「需要啟用 JavaScript」的空殼，一直沒把真正的介面載入出來。

這和連線好壞無關。PrintRelay 託管在 Streamlit Community Cloud，這是 Streamlit 的免費雲端，閒置一段時間會把 app 收進休眠，下次有人開才重新啟動。對示範用的 side project 無傷大雅，但對一個你想「臨時要印東西就開來用」的傳檔工具，這代表你急著用的那一刻，它可能正在慢慢醒來。app 在瀏覽器分頁的標題叫 Document Relay，和 PrintRelay 這個名字對不上，也側面說明這是個人開發者的作品，未必有團隊在持續維護。

實測時這段喚醒等待，反覆重新整理也難以立刻解決，因為 app 得重新啟動後端容器才會回應，時間長短取決於 Streamlit 當下的排程，沒有保證。換句話說，第一次開通常最慢，短時間內重開會順一些，但隔一陣子沒人用，又會退回休眠狀態。把這個特性算進使用節奏，才不會在影印店櫃檯前乾等。

短到只剩三步，是它真正的本事

按工具的設計，流程壓得很短。電腦端先開接收頁，畫面會吐出一個 QR Code 和一行「Listening for incoming encrypted payload」的等待字樣，代表接收端就緒。手機掃那個 QR Code，在開啟的手機頁挑要送的 PDF 或圖檔上傳，電腦那頭就能收到並下載。這段流程是依工具的設計說明描述，實測時介面卡在喚醒階段、沒有完整載入，真正要用前建議先讓它醒過來再操作。

全程不走配對、不走提取碼那套，也不必把任何社群帳號掛上去。在影印店、酒店商務中心、客戶辦公室這種公用電腦上，你不用把自己的帳號留在陌生設備裡，少了「印完忘記登出」的風險。手機不分 iOS、Android，能掃碼、能選檔上傳就夠用，電腦端有瀏覽器能開網頁就行。

免同區網的代價：檔案得過伺服器中繼

PrintRelay 常被提起的一個特色是「不要求同一個區網」，電腦連公司網路、手機吃 5G 也能傳。這個便利是真的，背後卻有個很少被點明的取捨：能在不同網路之間傳，代表檔案會先送到一個中間的伺服器，再轉給接收端，並非兩台設備直接對傳。也就是說，你的檔案在那幾秒鐘裡，是停在第三方伺服器上的。

把資料流向說具體一點：手機選了檔案送上傳，這份檔案先抵達 PrintRelay 背後那台伺服器（部署在 Streamlit 雲端上），伺服器再把檔案轉交給正在等待的電腦端。檔案在傳輸的那幾秒，是真真切切停在第三方機器上的，並非手機直送電腦。這條路換來「不用管兩邊在不在一起」，也換掉了點對點那種「只有你和對方知道內容」的結構。對一份要當場印出來銷毀的 PDF 無所謂，對一份合約底稿就值得多想一秒。

這和 LocalSend、AirDrop 那類同區網工具走的是兩條路。後者靠兩台設備在同一個網路裡直接點對點連線，檔案不經外部伺服器，前提是兩端都在同一個 Wi-Fi。PrintRelay 拿掉「同網路」這個前提，代價就是檔案得過一次伺服器。臨時印個履歷、合約，這個代價多半可以接受；若檔案內容不能讓第三台機器碰到，這條路就不該選。把這層講清楚，比單看「免區網」三個字重要得多。

「加密負載」只是頁面字串，談不上安全保證

接收頁面上那句「encrypted payload」（加密負載），很容易讓人以為傳輸有端到端加密保障。但它只是一句介面提示，告訴你「正在等待加密的資料進來」，至於加密發生在哪一層、是只有傳輸過程加密（瀏覽器常見的 HTTPS）、還是連伺服器都解不開的端到端加密，頁面和工具都沒有說明文件交代。

同樣的情況出現在「留存」上。PrintRelay 主打臨時中繼、傾向最小化留存、工作階段結束後清理，聽起來乾淨，但「工作階段結束後清理」是設計取向的描述，不是寫明白的保留期限。究竟檔案在伺服器停多久才清掉、有沒有備份殘留、清理是否自動且不可逆，都沒有公開條款可查。檔案又實際過 Streamlit 雲端，留存與隱私還疊了一層託管平台政策。把這些當成「應該沒事」而不追問，是臨時工具很容易被忽略的風險。

加密可能發生在三個層次。最底層是傳輸層加密，也就是瀏覽器和伺服器之間的 HTTPS，幾乎所有現代網頁都有，能擋住傳輸路上被偷看，但檔案到了伺服器端是明文存在。再往上是應用層加密，檔案在送出前先在手機端加密、抵達伺服器時是密文，要看機制設計。最嚴格的端到端加密則連伺服器都解不開，只有接收端有鑰匙。PrintRelay 頁面那句提示無法判斷屬於哪一種；沒有白皮書或條款說明的情況下，保守把它當成只有傳輸層保護，是比較穩的心態。

跑在 Streamlit 免費版上：休眠、冷啟動、沒有 SLA

免費託管的好處是不用自己部署，代價是你沒辦法要求它隨傳隨到。PrintRelay 部署在 Streamlit Community Cloud，這個免費平台有些固定特性：閒置會休眠（實測打開時就遇到），喚醒後冷啟動需要時間（實測約兩分鐘仍未完全載入），沒有服務等級協議，資源和流量也有限制。對示範專案無所謂，但對一個你想穩定仰賴的傳檔通道，這些都是變數。

實際影響是：會議現場急著把簡報送到主辦單位的電腦，掃碼前可能得先等 app 醒過來；網路不穩的影印店，大檔案在中繼過程也更容易卡住。這與 PrintRelay 本身無關，純粹是免費託管平台的先天限制，挑這類工具時把它算進成本，才不會在關鍵時刻被坑。

跟其他傳檔工具擺一起，它卡在哪個位置

檔案傳輸這個類別已經很擠，把 PrintRelay 放回去看會更清楚它的位置。會產生 QR Code 的 transfer zip 走點對點，檔案不過伺服器；主打無大小限制的 FastSend 也是 P2P 加密路線；同樣免註冊的 AuraShare 偏向產生限時連結給對方下載。這些工具多半要你或對方主動開連線或連結，檔案流向比較看得到。

PrintRelay 的差異在於場景收得很窄：手機掃碼、送到電腦、當場印出來，全程不要在公用機器上留帳號。它取代不了 P2P 工具，畢竟過伺服器這一點就輸給同區網點對點的隱私結構；它也填不了 rDrop 那種能一直掛著傳大檔的需求。它卡的是「人在外面、借用別人電腦、只想印個東西」這個縫隙，把它放對位置，才不會期待錯方向。

工具	連線方式	檔案是否過伺服器	最適合的場景
transfer zip	點對點（QR 或連結）	否（P2P）	兩端能配合、要即時對傳
FastSend	點對點加密	否（P2P）	大檔案、不計大小
AuraShare	限時連結	是（產生連結取件）	給對方一個限時下載連結
PrintRelay	掃碼中繼（跨網）	是（伺服器中繼）	公用電腦臨時列印、免帳號

從這張表看得出來，PrintRelay 占的是「過伺服器、但換來免區網與免帳號」那一格。它和同樣過伺服器的 AuraShare 差在投遞方式：AuraShare 給你一個限時連結，PrintRelay 給你一個 QR Code 直接指向接收端。選哪個，取決於你要把檔案交給「會自己點連結的人」，還是「眼前那台不想登入的電腦」。

適合拿來傳什麼，不適合傳什麼

PrintRelay 適合的範圍其實很明確。適合的是體積小、要馬上用的檔案：馬上要印出來的求職履歷、證件照，當場要簽字的合約或報價單，會議中臨時要塞給主持人的圖檔或 PDF。這類檔案傳過去、印完或用完就結束，不在乎伺服器中繼那一兩秒，休眠喚醒的等待也在可接受範圍。

不適合的也一樣明確。別把它當雲端硬碟塞幾 G 的影片進去，跨網中繼經不起頻寬抖動，大檔很容易卡在中途；更別拿來傳高度敏感的資料，例如整份的登入清單、還沒公開的薪資表、仍在談判中的報價底稿。這類東西該走離線管道，USB、內網，或真正端到端加密、免後端的傳遞工具，例如 DropLock 這種把加密做在檔案本身、不靠第三方伺服器解密的方案。PrintRelay 的定位是臨時投遞，把這條線畫清楚，它就是順手的小工具；越界使用，便利就會變成風險。

在公用電腦上用這類工具，幾個習慣能再降低殘留風險。下載時避開桌面那種一眼可見的位置；印完順手清掉下載夾裡的原件；最後把接收頁關掉，並確認瀏覽器沒留下登入狀態或下載紀錄。這些動作和選哪個工具一樣重要，PrintRelay 幫你省的是「登入帳號」這一步，沒幫你省「檔案落地在公用機器上」這件事，後者還是得自己收尾。