把閱後即焚連結貼進會產生預覽的聊天之後，閱讀次數為什麼不一定已經被用掉

把一條 https://…/s.html?id=…#… 貼進 Slack、LINE、Discord 或 Microsoft Teams 之後，輸入框或訊息下方常常先跳出一張小卡片：標題、一兩句摘要、有時還有圖示。很多人把這張卡片讀成「連結已經被開啟過了」。順序其實相反。聊天軟體要先向這個位址發一次 HTTP GET，從回傳的 HTML 裡抽出 og:title、og:description 或普通 <title>，再畫卡片。接收方此時可能還沒點進去。

Slack 把這件事寫進了官方說明。預設情況下，使用者和 Slack 應用程式發出的、帶完整網址的訊息都會展開連結；媒體內容也可以展開。英文技術說明見 Slack 文件《Unfurling links in messages》；繁中產品說明則把同一行為叫做「連結預覽」，見 Slack 說明中心〈分享連結及設定預覽偏好設定〉。專門負責展開連結的機器人自稱 Slackbot-LinkExpanding 1.0 (+https://api.slack.com/robots)。同一頁 Slack Robots 寫明：它會盡量少取頁面（使用 HTTP Range），目標是 oEmbed、Twitter Card 和 Open Graph 標籤；如果標籤指向圖片、影片或音訊，才會再取那份檔案做校驗。回應大約快取 30 分鐘。文件沒有寫「執行頁面上的 JavaScript」或「替使用者點按鈕」。

瀏覽器發出這次 GET 時，# 後面的內容不會進入請求列。IETF RFC 3986 §3.5 把 fragment 定義成用戶端識別，不參與伺服器對 URI 的處理。所以預覽機器人即便完整複製了你在聊天框裡看到的字串，真正打到 UsePwd 的請求通常只到 s.html?id={編號}。金鑰為什麼不進存取日誌，見已有文章URL 的 # 片段為什麼不會出現在伺服器日誌裡。本篇要補的是另一層：這次不帶金鑰的 GET，算不算「讀過一次」。

不少一次性連結把密文直接掛在被預覽的那個 URL 上：機器人 GET 一次，伺服器就回傳正文並刪除紀錄。接收方隨後點開，看到的是「已被閱讀」或 404。這個失敗很常見，原因不是 Slack 或 LINE「惡意燒掉秘密」，而是實作把 RFC 裡本該安全、可快取的 GET，當成了「銷毀密文」的動作。

UsePwd 的閱後即焚把三步拆開。建立時，當前分頁用 Web Crypto 按 AES-256-GCM 加密，明文上限 32 KB；上傳欄位只有密文、過期時間和閱讀次數。過期時間可選 1 小時、24 小時、7 天，或「僅閱後焚毀」；閱讀次數 1–10，預設 1。連結形態是 s.html?id={id}#{key}。建立頁和閱讀頁都開啟即用，雙方都不用註冊。伺服器只暫存密文，看不到明文，也沒有帳號可以按使用者找回。

接收方開啟閱讀頁時，頁面先向 /api/secrets/{id}/status 詢問密文還在不在。這一步只回傳 active、burned 或 expired，不增加閱讀計數，也不刪除紀錄。只有點了「開啟並檢視」，瀏覽器才會請求 /api/secrets/{id} 取回密文，並在本機用 # 後的金鑰解密。達到建立時設定的次數後，伺服器刪除密文；再取會得到 410。預覽機器人停在落地頁 HTML，常見情況下既沒有金鑰，也不會去點那個按鈕。

Slack 的連結展開機器人、Discord 用來產生嵌入卡片的抓取、LINE 把網址收成一張預覽的伺服端請求，以及 Teams 的類似展開，都屬於同一類：先 GET 頁面，再從 HTML 裡找標題和摘要。台灣站點實測時，LINE 的網址預覽常見 User-Agent 會帶 facebookexternalhit 與 line-poker，對照見 黑暗執行緒〈美美的 FB/LINE 連結預覽是如何產生的？〉。這類抓取讀的是靜態標籤，不是替你按下「開啟並檢視」。

Slack 另外說明，它不把 robots.txt 當成傳統爬蟲規則來遵守，因為展開連結是「替發連結的人辦事」，不是順著站點亂爬。你在閱讀頁加 noindex，擋得住搜尋引擎收錄，擋不住頻道裡的那張卡片。UsePwd 的閱讀頁本身是臨時密文場景，帶 noindex, nofollow，也不進網站地圖。頁面標題固定寫成「開啟閱後即焚連結」，描述只說明解密在當前分頁完成、金鑰在 # 後面。預覽卡片若成功產生，頻道或群組裡看到的就是這句通用說明，不會出現你寫入的密碼、Token 或工單原文。這和「伺服器日誌裡有沒有金鑰」是兩件能同時成立的事：卡片證明有人 GET 過落地頁；日誌裡仍然沒有 fragment。

Slack 寫過，同一 URL 的展開結果大約快取 30 分鐘。短時間裡把同一條測試連結反覆貼進頻道，不一定會看到第二次抓取。要核對「機器人來過沒有」，應看你自己的存取日誌裡有沒有 Slackbot-LinkExpanding、Discordbot 或含 line-poker 這類 User-Agent，而不是盯著卡片重新整理幾次。日誌裡出現對 s.html 的 GET，仍然不能推論「/api/secrets/{id} 已被呼叫」。

最常見的消耗者是接收方本人：開啟完整連結，看到「密文還在」，再點「開啟並檢視」。預設次數是 1。這一次成功之後，伺服器刪除密文；同一條連結再開啟會提示已被焚毀。若建立時把次數設到 2 或更高，前幾次取回後密文仍在，直到計數達到上限。過期時間到了也會刪除：預設 24 小時，也可以是 1 小時、7 天；選「僅閱後焚毀」則只按次數刪，不按鐘點刪。

第二類是會執行腳本並且模擬點擊的環境。部分郵件安全閘道、連結沙箱會在隔離瀏覽器裡開啟網址，有的還會點頁面上的主按鈕。那已經不是「產生一張卡片」，而是另一次完整的、像人一樣的存取。若沙箱點了「開啟並檢視」，次數會被用掉，接收方隨後看到焚毀態。這一層要用閘道自己的報告核對，不能從聊天卡片反推。

第三類是把取密文的介面位址直接發出去。閱讀頁位址是 s.html?id=；真正消耗次數的是 /api/secrets/{id}。一般使用者不會複製後一條。若有人把介面 URL 貼進會預覽的頻道，而那家工具又把第一次 GET 當成取密文，次數會在預覽階段被用掉。UsePwd 的分享形態不走這條位址，建立頁複製的是帶 # 的閱讀頁連結。

聊天軟體保存的是你貼出去的整串位址。誰能搜尋歷史、匯出工作空間、開啟備份，誰就能再次開啟閱讀頁。次數還在時，後開啟的人仍可能點「開啟並檢視」並讀到明文；次數用盡後，紀錄裡留下的是一條已焚毀的連結，加上當時的卡片標題。管理員匯出改不了伺服器上已經刪除的密文，但改不掉「當時頻道裡出現過完整網址」這件事。

截圖和轉發是另一份副本。有人把閱讀成功後的明文截下來，或把連結轉到另一個會預覽的群，邊界就從「這一次 GET」變成「下一跳還經過誰」。閱後即焚限制伺服器上密文的壽命和次數，不限制接收方是否截圖。UsePwd 沒有帳號和密碼庫，也不能按使用者找回丟失的連結。需要長期保存或多裝置同步時，應使用專門的密碼管理員。身分說明見關於。

檔案是第三條路徑。單檔不超過 5 GB 的本機備份，走檔案加密盒，輸出 .lock / .enc，檔案預設不上傳。口令本身用密碼產生器在 6–128 字元之間產生，再用密碼檢測看強度。這些頁面和本篇一樣開啟即用。不要把「預覽沒燒掉次數」理解成「貼進任意頻道都安全」：聊天紀錄和預覽抓取不是同一層。