執行逾時了，Vercel 的免費方案 只給你 60 秒回應。假如你的 /upload 等待回應的時間超過 60 秒，那就會被 Vercel 殺掉哦。 有三種解法： 如果不想花錢，就想辦法把任務放到背景，如圖一。不過我翻了一下 Vercel 的文件，它沒給你機會建立一個超過 60 秒的任務，所以你大概得在 Cloudflare Workers 用 JavaScript 重寫你 Gemini 等待回應那段邏輯，用 waitUntil 把任務移到背景執行，接著將回應寫進資料庫，你的前端再不停呼叫 response 等回應。注意 Cloudflare Workers 的免費方案有 100,000 次的觸發限制，而一輪會至少觸發 2 次。 升級到 20 美元的 Vercel Pro，他會慷慨的多給你 12 分鐘回應。 試試看 5 美元的 Zeabur，不限制回應時間，你想處理多久就處理多久。
今天吃飯聽到隔壁桌剛好在討論 vibe coding，然後就在講『跟 AI 說要建立「資料夾」但沒想到 AI 竟然說「目錄」？？？目錄不是支語嗎？』 嚇到我了，我以前也講目錄欸，目錄真的是支語嗎？當然後來都說是資料夾了 🤔 Post folder（面向使用者的用詞）和 directory（檔案系統概念）的不同。無論是「資料夾」還是「目錄」，這兩個都是老資訊用詞了，都不是支語 ⚠️ btw folder 在 macOS 上會翻譯成檔案夾，雖然和微軟系的「資料夾」差得有點多，但這真的不是支語 ⚠️⚠️ 補上 Apple、Microsoft 和 GNU coreutils 對 folder / directory 的詞彙表。GNU coreutils 基本上就是常見 Linux 發行版內建指令列工具對應的翻譯。 其他公司和軟體的對應翻譯也可以自己找，但不要把不認識的詞當成支語 QQ
我有看過一種做法是 api 直接在 server side 直接吐完整包列表資料，前端在自己做 pagination, 我不知道這樣做跟 api 做 pagination 比有沒有優勢 Post 原則上，如果抓資料的開銷和筆數有關，我會設計 API 層級的分頁：API 比較不需要讓資料庫查太多東西 (SELECT all) 而造成資料庫壓力，也不會一次下載太多沒必要的資料回來。 如果資料量沒這麼大（比如一些 Tags），我會讓 client 分頁，純粹只是為了改善前端體驗。如果資料量大一點（比如 1K），我就會傾向在 API 設計基礎的分頁功能（即便對後端來說，取多少筆資料都不會影響速度），來減少需要回傳的內容。 By the way 後端分頁也有他的學問，傳統的 offset-based pagination 在資料筆數非常大的情況下，可能會有效能問題。可以看看比如 Cursor-based pagination 的知識，或許對以後設計超大資料的分頁 API 會有幫助。
renderList ……？討論串很多人針對這篇評論給出很多不同建議了，我想給幾個我還沒看到的 point。 關於「元件最佳化」這點：React 背後有 Virtual DOM，所以你 render 100K 遍一樣的 list，相同 key、相同內容的 element 是不會在實體 DOM 層被重建的；useMemo 如果 list 的內容會一直變動，反而可能會造成 memory leak。如果是新專案，我通常推薦不手寫 useMemo/useCallback/memo 等等的記憶函式，直接讓 React Compiler 分析哪些東西該被 memorized。 既然 React 不會一直重建那 100K 個 DOM 元素，那為什麼在非常大的 list 下還是會卡？因為瀏覽器不擅長處理過多 DOM 元素。這種情況下應該要用 Virtual List 來只 render 可見元素，壞消息是他有 trade off——無法選取超出 viewport 的內容、瀏覽器內建搜尋不能搜尋全文。所以就算 GitHub 那種程式碼 view 很適合 Virtual List，但實際上都沒有實作。
如果伺服器傳送 Etag: 1233，過了 CDN Client 收到 Etag: W/"1233" 那麼 Client 回送 If-Match 應該傳送 W/"1233" 還是 1233？ Original Post If-Match 的用意是在於防止「更新遺失」或「中途編輯衝突」（mid-air edit collision）。它的核心用途是在執行條件式請求時，確保用戶端操作的資源版本與伺服器上的目前版本完全一致1。 如果 CDN 傳送 Etag: W/"1233"（weak validator），因為 If-Match 標頭要求使用強比較函式1（即 E/1 ≠ E/12），因此用戶端無法使用這個值來建立 If-Match 條件式請求1。因此，如果伺服器傳送的是 Etag: W/"1233"，則不應該在 If-Match 中傳送任何值來進行條件式更新。 如果要做快取的話，直接記錄 ETag，日後用 If-None-Match header 讓伺服器比較版本就行3。通常來說 If-Match 都是防止狀態改變的方法（POST 這些）1，CDN 通常不會去快取 POST 這類主要做 mutation 的方法，也就沒必要把 ETag 改成 weak representation，也就不太會遇到這個問題。 RFC 7232 – Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests – If-Match: https://datatracker.ietf.org/doc/html/rfc7232#autoid-15 ↩︎ ↩︎ ↩︎ ↩︎ RFC 7232 – Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests – ETag Comparsion: https://datatracker.ietf.org/doc/html/rfc7232#autoid-11 ↩︎ ...