有段时间开发和部署都挤在同一台小规格云主机上。服务起来其实不重，三两个容器内存加起来也不吓人；吓人的是磁盘和内存被镜像缓存、依赖目录、远程 IDE 一起咬住，再跑一次全量构建就容易喘不过气。
盘上大头往往不在业务源码，而在容器镜像层和构建缓存。仓库目录里也是依赖体积远大于手写代码。于是出现一种错觉：线上很闲，机器却已经紧——因为「闲」的是请求，忙的是开发期副作用。
静态站点这边另有一套误解。落地页、组件文档、博客各自独立构建，挂在不同路径下，本意是互不踩配置。实操时容易默认「覆盖源码目录就等于用户看见新资源」。模型文件、带 hash 的资源、网关缓存，任一环节旧了，浏览器仍可能渲染上一版。博客和文档站坚持独立产物、明确 base，就是为了少踩这种混部坑。
文档站里后来加了纯前端低代码组装：本地存结构、导出 HTML。第一版用网页本地键值存储，图省事。组件树一大，就碰到容量天花板——不是业务逻辑错，是存储选型太窄。
运维侧：把「能回收的」和「运行必需的」分开看——构建缓存、无用镜像、本机重复依赖可以清；运行中的数据卷谨慎动。中长期更想把重开发挪到本地机器，云上只负责拉代码部署，避免小机既当 IDE 又当构建农场。
静态站：每个子站自己的构建产物和挂载路径写进部署说明；更新资源时确认实际对外目录，而不是只看仓库工作树。
低代码：草稿改存浏览器数据库，容量比键值存储宽裕得多，并保留失败提示，避免静默丢稿。导出 HTML 时样式文件的引用也踩过打包别名解析问题，后来改成构建期能稳定读到的路径，导出页才不会缺皮。
生成物预览、文档站、博客，原则其实一样：产物隔离、路径说死、更新看最终托管层。小机器逼人把这句话念熟——资源紧的时候，架构洁癖会从偏好变成生存技能。