对的，我又熬了一晚，这次对网站一些内容做了优化

一、移动端

之前导航栏会黏在一起，还有按钮被标题覆盖的问题解决了

二、后台

由于网站是没有数据库的，是直接读取仓库下的内容，每次在后台提交新内容就会触发重新部署，等个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;
    // ...
  }
}

服务器其实比较“笨”，它只是机械地把发过来的清单执行一遍。真正的智能逻辑（去重、覆盖、撤销）都在前端做完了。

具体图片：