DSHBox 里的 guest 是 Debian 13（trixie），不是"看起来像"的仿制品。所以标准
包管理器都能用：apt 装系统工具，npm（连同
npx 和 corepack）管 Node.js 24 这一侧。真正容易忽略的是：装上去的
包去了哪里，更新时又会发生什么。这个分界在导入完整运行时包之前最值得
弄清楚——那是唯一会重置各层的路径。
是真的 Debian，就有真的包管理器
内置工具集已经覆盖日常：bash、vim、htop、node、npm、apt、git、python3、ssh。
需要超出这份清单的东西时：
- 系统工具——先
apt update，再
apt install <包名>，和任何 Debian 机器一样。
- JavaScript 工具——命令行工具用
npm install -g <包名>，或者在工作区里做项目级安装。
包到底装进了哪里
你安装的任何东西都不会进工作区。包装进了应用私有存储内的运行时层：apt 包
解压到基础层——也就是成为 guest 根目录 / 的那套 Debian rootfs；
全局 npm 工具进入 node 层区域，挨着 /usr/local 下的 Node.js 24。
层和工作区共享同一块存储，没有单独的"系统盘"可言；大型安装前后用
df -h 看一眼余量，是个值得保持的习惯。存储管理在
"设置 → 存储与清理"；整体布局见
《DSHBox 把数据存在哪，怎么备份》。
哪种更新能留下什么
更新路径有三种——普通的应用更新、只替换 dsh 层的 DSH 更新、换掉基础三层的
完整运行时导入——它们对已装包的态度各不相同：
|
| | 内容 | 所在位置 | 应用更新 / DSH 更新 | 完整运行时导入 |
|---|
工作区文件（/root/projects） | user-data/ | 保留 | 保留 |
| DSH 配置 | user-data/.dsh | 从不触碰 | 从不触碰 |
| apt 包 | 基础层 | 保留 | 被替换——需重装 |
| 全局 npm 工具 | node 层区域 | 保留 | 被替换——需重装 |
完整运行时包的导入会整体替换基础层、node 层和安卓侧层（保留一份 previous
副本用于回滚），装进这些层的工具随之而去。任何更新路径都不会碰
user-data/ 和 .dsh。
DSH 层更新是最温和的那种
更新 DSH 本身——无论在线还是离线——只替换 dsh 层，即挂载在
/opt/dshapp/runtime 的那个 npm 包。你用 apt 和 npm 装的东西不在
这一层，完全不受影响。换句话说，你最常做的那种更新，恰恰是永远碰不到
你自己安装的东西的那种。在线更新会并行探测 npm 官方源以及阿里云、腾讯、
华为镜像；离线更新则导入层文件。细节见
《更新 DSH 与 DSHBox》。
让重装变便宜的习惯
- 在工作区里留一份安装清单。
/root/projects 下
一个简短的脚本或包名列表能扛过所有更新路径——运行时导入之后，重装就是一次
粘贴的事。
- npm 优先项目级安装。在
/root/projects 的项目里
直接 npm install，别用 -g：包落在工作区，什么更新
都扛得住。
- 导入之后查一眼 guest。花十秒确认少了什么，好过干活干到
一半才发现。
把这份清单当成你的 dotfiles 仓库：短小、有版本、无聊——恢复只要几秒。
一个完整的例子
装一个小型命令行工具，验证，再看运行时导入之后的"打破玻璃"步骤：
df -h /
apt update && apt install -y jq
jq --version
现在 jq 住在基础层里，普通的应用更新都带得走。等你哪天导入完整运行时包，
基础层被替换，jq --version 会失败——把同样两行再跑一遍，或者执行
你留在工作区里的安装脚本，就能恢复原状；整个过程不重装应用，也不动工作区
里的任何文件。日常终端技巧见
《内置终端》；git 相关的习惯见
《口袋里的 Git》。