在本地删错了文件还能去废纸篓里捞，在阿里云 ECS 上没有这层缓冲。DSH 的归档会话一旦执行物理删除，会话元数据和磁盘数据文件会一起消失，云盘不会替你后悔。这篇不谈功能，谈规程：一套在服务器环境下安全清理会话归档的操作纪律，适合贴在团队内部当 checklist 用。
第一条纪律：把每次删除都当成不可逆操作
Codex 归档管理插件的「物理删除」会同时清掉会话元数据与磁盘数据文件，用途是释放存储空间——它没有回收站，也没有恢复机制。ECS 数据盘上的数据一旦删掉，除非你恰好开启了快照策略，否则找不回来。
所以规程的起点永远是：任何删除动作之前，先完成预览确认。插件支持不恢复会话直接看内容，点「查看内容」就能在弹窗里浏览该会话最近 50 条用户/助手消息，系统注入文本会被自动清理掉。但这个预览有边界：只展示最近 50 条，更早的内容预览不到。如果一条会话你拿不准该不该删，正确做法是先点「恢复会话」还原回原工作区，看全内容再做决定，而不是凭标题和日期猜。
动手前的备份规程
dsh 和插件都处于 developer-preview 阶段，任何批量操作前先备份 ~/.dsh（或你的 $DSH_HOME）。在 ECS 上一条 tar 命令就够：
如果你把 DSH_HOME 规划到了数据盘，把命令里的路径换成对应目录。备份文件建议放在系统盘，和数据盘物理隔离，避免磁盘级故障时一起丢。重要项目可以再打一份 ECS 快照，成本很低，换到的是「随时能回滚」的底气。
按项目批量清理的标准流程
归档管理按工作区/项目自动分组，每组带项目图标、对话计数和磁盘占用，组上的 ··· 菜单支持一键「删除项目中的全部内容」。批量删除效率高，也最容易误伤，建议按下面五步走：
- 巡检：展开归档管理卡片，逐个项目看对话计数和磁盘占用，先心里有数哪些组该清。
- 抽查预览：在每个准备删除的项目组里，抽两三条会话点「查看内容」，确认这些确实是可以丢弃的历史。
- 整体备份：执行任何组级删除前，跑一遍上面的 tar 备份。
- 组内执行：用 ··· 菜单按项目删除，不要在多个组之间连续快速点击，删一个核对一个。
- 事后核对：删除后回看磁盘占用是否下降，侧边栏归档列表是否正常——插件的 Live Sync 会把变动实时同步到侧边栏，这也是核对手段之一。
安装与升级后的例行检查
无论你是 npm 线上安装，还是用 link 方式挂本地开发目录，装完都做同一件事：打开 $DSH_HOME/profiles/web/package.json（未设 DSH_HOME 时为 ~/.dsh/profiles/web/package.json），检查 dsh.profile.bundles 数组里只包含根包 @mlgbnb/dsh-archive-manager、不掺子组件包——link 方式同样会遇到子包重复声明导致的启动报错，这个检查不能省。
升级 dsh 之后还要做一次复查。这个插件的实装验证结论是在 dsh 0.1.5-rc.3 下取得的，当前 dsh 已更新到 0.1.7-rc.2，档位标着「待复验」；它运行时读取 storages/workspace.json、storages/session_projcache.json 和 sessions/ 目录这些内部结构，上游一改就可能失效。所以每次 dsh 升级后的固定动作是：先备份，再打开归档管理确认列表能正常加载，然后才恢复日常清理操作。别把「曾经验证通过」当成「现在没有问题」。
把网络边界也纳入规程
在 ECS 上跑 DSH Web，访问 3080 端口优先走 SSH 隧道而不是对公网开放安全组；如果必须走安全组，授权对象限定为你自己的固定 IP。另外别忘了出方向：静态扫描显示插件具备发起外部网络请求的能力，对出网管控严格的环境，可以通过安全组出方向规则做最小化放行。实例规格不用追大，通用算型 2 vCPU 足够，重点在磁盘与数据安全，不在算力。
总结
服务器环境里删数据，慢一点反而就是快一点——先预览、再备份、后删除、最后核对，这套动作固定下来，归档清理才不会变成高危操作；
适合与不适合
适合：在阿里云 ECS 上长期运行 DSH、归档会话持续堆积的开发者；管理多人共享服务器的运维，需要一套可交接的清理规程；对数据安全敏感、希望删除操作有备份可回滚的团队。
不适合：期望删除后能一键找回的人——物理删除没有回收站，规程替代不了后悔药；只用 CLI/TUI 的用户，插件仅在 Web Profile 下有入口；无法接受插件发起外部网络请求、又没有能力做安全评估的环境。
