對的，我又熬了一晚，這次對網站一些內容做了優化

一、移動端#

之前導航欄會黏在一起，還有按鈕被標題覆蓋的問題解決了

二、後台#

由於網站是沒有數據庫的，是直接讀取倉庫下的內容，每次在後台提交新內容就會觸發重新部署，等個30秒左右，太浪費時間了，就想著能不能暫存起來，然後再一併提交上傳，然後花了點時間優化了這個玩意！

1、攔截 (Interception)#

整個流程完全在你的瀏覽器（客戶端）和服務器（Next.js API）之間流轉：

當你在編輯器點擊 + ADD TO BUFFER 或者在列表點擊 [DEL_STAGE] 時：

程序阻止了表單的默認提交行為（不再直接發請求給服務器）。

程序把你的操作意圖打包成一個 JSON 對象（Action Object）。

比如：{ type: "DELETE", file: "post-1.md" }

2、通信與存儲 (Event & Storage)#

因為「編輯器組件」和「底部的暫存條組件」在代碼裡隔得很遠，它們怎麼由通信？

自定義事件 (Custom Event)：編輯器發出一個名為 add-to-staging 的廣播信號。

監聽器：底部的 StagingManager 組件一直在監聽這個信號。一旦聽到，就把數據抓過來。

去重邏輯：StagingManager 會檢查：「這個文件之前操作過嗎？」

如果之前是「修改A」，現在是「修改B」，它會把A刪掉，只保留B（只保留最後一次狀態）。

如果之前是「修改」，現在是「刪除」，它會直接變成「刪除」。

持久化：將整理好的數組存入瀏覽器的 localStorage。

作用：即使你不小心刷新了頁面，或者關掉了瀏覽器再打開，暫存區的數據依然還在，不會丟失。

3、批量提交 (Batch Execution)#

當你點擊底部的 PUSH TO CLOUD 按鈕時：

前端把 localStorage 裡存的那一堆操作數組（比如裡面有3個修改，2個刪除），一次性打包發給服務器。

Server Action (batch.ts) 接收到這個大數組。

服務器開始 for 循環，依次執行每一個操作（調用 GitHub API）。

所有操作執行完畢後，通知 Vercel：「數據變了，請重新構建網站」。

三、代碼層面#

1、在 src/components/AdminPostForm.tsx 中：

const event = new CustomEvent("add-to-staging", { detail: newItem });
window.dispatchEvent(event);

編輯器不需要知道暫存條存不存在，它只管廣播「我要存東西」。底部暫存條也不需要知道是誰發的，它只管接收。這讓代碼結構很清晰。

2、在 src/components/StagingManager.tsx 中：

localStorage.setItem("nebula_staging_buffer", JSON.stringify(next));

這是為了防丟。React 的 state (useState) 在刷新頁面後會清空。如果不用 LocalStorage，你辛辛苦苦暫存了10篇文章，手抖刷新一下就全沒了。

3、在 src/app/actions/batch.ts 中：

for (const op of operations) {
  switch (op.type) {
    case "DELETE_POST": await deleteGithubFile(...); break;
    case "SAVE_POST": await saveGithubFile(...); break;
    // ...
  }
}

服務器其實比較「笨」，它只是機械地把發過來的清單執行一遍。真正的智能邏輯（去重、覆蓋、撤銷）都在前端做完了。

具體圖片：