預覽本來想畫完整份，量完記憶體之後改畫前面一段

9 月 23 日凌晨我核准了大檔預覽的計畫。上午量測跑完，數字把計畫改寫了。App 跟 Finder 的空白鍵預覽共用同一套上限：超過約 1 MB 就不硬畫整份，改成前面一段摘錄，並加一行人看得懂的提示。摘錄自己也有界，最多約 64 KB、2000 行。

我晚上問，這到底是在修效能嗎。聽完之後我說，絕大部分情況都不會出錯的話，可以到此為止。怕太邊角的案例拖上線。

---

一開始的上限寫得比較鬆，等量測再說。寫程式的 agent 先把規則抽成一份共用定義，兩邊走同一套判斷。讀檔時避開會卡住的特殊檔案，逾時就退回摘錄。Finder 那邊還多一道時間上限：讀檔、解碼、渲染合計超過約 2.5 秒，一樣改走摘錄，免得按一次空白鍵把系統預覽卡死。

量測把「大方一點的摘錄」推翻了。大量短行時，畫頁面的輔助行程記憶體會被推到危險邊緣。收到 64 KB、再加行數上限，數字才回到可接受的範圍。於是兩邊都寫死 1 MB。註解裡直接引用量測的那幾列，以後的人知道這不是拍腦袋的數字。

裁摘錄時還有一個安靜的洞。若把任何高位元組都當成未完成字元的開頭，一整段無效資料會少掉最後一個位元組。測試先在還沒修的版本上抓到它。邊界若會咬掉內容，那個邊界就不算數。

大檔的上限是量出來的。剩下的邊角，我停在上線之前。

收尾

檢查清單不再寫「記得手動試一次大檔」。腳本自己建一份會撞上限的樣本，看預覽有沒有老實退回摘錄。人若只記得昨天好像有擋過，下一版還是可能把整份又畫回去。

先不說了，我得去拿一份超過 1 MB 的文件按一次空白鍵，看那行提示還在不在。

這件事發生於 2026 年 9 月 23 日，文章整理於 2026 年 10 月。