我對某件事感到驚訝，所以我寫了一篇文章來介紹。
第一次測試 ISR，這是 Next.js 提供的一個非常酷的功能。
基本上，我們可以在構建時靜態生成網站，因此一開始就提前獲取了所有的數據，然後 Next.js 提供了網頁的緩存版本。
但是我們也可以告訴 Next.js 網頁應該每隔 n 秒重新驗證一次。
所以我們可以設置（Next.js 13 應用文件夾）：
export const revalidate = 30
然後每 30 秒重新驗證一次該頁面。
該頁面會以超快的速度提供給在上一次驗證後 30 秒之後首次訪問該 URL 的用戶（需要有人在重新驗證之前訪問該 URL，它不是一個定時任務），但在後台它會再次構建，完成任何需要進行的數據獲取。
這很酷。
但在 Vercel 上，重新驗證流程運行在一個無服務器函數中。
這讓我花了好幾個小時來解決一個我認為是一個 BUG 的問題（新的應用程序文件夾仍處於 beta 階段，所以可能會發生），但是我要麼沒有閱讀正確的文檔，要麼文檔並沒有很好地記錄。
重新驗證的無服務器函數運行在與第一次構建不同的環境中。
第一次構建可以寫入文件系統。重新驗證的無服務器函數無法這樣做。它可以寫入系統的臨時文件夾，您可以使用 os.tmpdir()（首先需要 import os from 'os'）獲取該臨時文件夾，但與其他構建之間沒有"通信"。
我試圖下載一些圖像，並將其作為站點的一部分，但這種工作流程是行不通的。
此外，我們無法訪問原始構建中下載的先前文件，因為我們看不到它們，我們處於全新的環境中。
這可能在無服務器函數環境中是常識，但對我來說是個驚喜。
不管怎樣，一旦您了解到這一點，您就會知道限制並找到解決方法。
例如，我可以將資源託管在 S3 上，或者像我最終為快速解決方案所做的那樣，將小圖像編碼為數據 URI。
哦，還有一個提示：為了調試重新驗證，我使用了按需重新驗證，這真的很酷。
因此，我可以訪問 API 端點來重新驗證特定的頁面路由，而無需等待重新驗證的時間。
使用按需重新驗證的一個坑點是，我在一個不獲取數據的路由上啟用了重新驗證（因為我將所有要解決的問題）從中剝離了所有數據獲取），當我嘗試使用 ODR 時，我遇到了這個問題，它顯然表示無法完成重新驗證，因為沒有數據可以重新驗證。基本上，它被標記為服務器錯誤，但實際上不是。這可能是一個在以後的更新中被修復的問題，請記住本文章的日期。
