在服务器上运行Hexo博客，磁盘空间告警几乎是每个博客维护者都会遇到的问题。静态博客虽然部署简单，但服务器上往往同时保留了源码、依赖模块、生成的静态页面、日志文件，甚至多份备份。这些文件混在一起，若是凭感觉“删一删”，很容易误伤用于日常维护的重要数据。安全清理的关键在于：先弄清每个目录的作用，再用可恢复的方式处理，而不是看见大文件就直接删除。
先诊断空间占用：不要凭猜测动手
遇到磁盘不足时，第一步并不是急着找什么可以删，而是用命令查看空间到底被什么占用了。建议先在博客目录下运行查看目录大小的命令，确定源码目录、部署目录和依赖目录分别占了多少空间。还要注意查看服务器系统分区本身的情况，因为日志文件、系统更新缓存以及数据库文件也可能占据大量空间，它们并不属于博客项目本身。由于服务器上跑的服务各有不同，账号权限和目录归属也各不相同，建议先确认当前用户对这些目录是否有删改权限，再决定从哪里入手。
优先清理可再生的目录：依赖与生成文件
在Hexo项目中，依赖目录和生成目录是最值得优先考虑的清理对象。依赖目录会随安装的插件积累越来越大，但它是完全可重建的，只要保留好记录依赖关系的清单文件。生成目录存放的是博客发布的静态页面，它在每次执行生成命令后都会重新构建。也就是说，只要源码还在，这两个目录就算被彻底删除也不会造成无法恢复的损失。
实际操作时，可以考虑彻底删除依赖目录和生成目录，然后重新执行依赖安装与博客生成命令。为了不影响的正在运行的网站，建议先把旧生成目录改名，再生成新目录，确认网站访问正常后再删除改名后的旧目录。这种做法比直接删除更稳妥，也让现场有回退的余地。
源码与版本历史：能压缩，慎清理
如果清理完依赖和生成文件后，磁盘空间依然吃紧，下一步要关注的是源码目录本身，尤其是版本历史文件。每次提交代码、切换分支、调整主题时，都可能留下历史快照。这个目录本身可能比全部源码还要大。但版本历史往往记录着排查问题的线索，清理它之前必须想清楚：是否不再需要回退到旧版本？是否已经将仓库推送到远端的代码托管平台备份？如果回答都是肯定的，可以尝试压缩或重建版本历史，而不是直接删除整个目录。
源码目录里如果有用户上传的图片、自定义的主题配置、或其他生成的数据库文件，不要当作垃圾处理。这类文件不具备可再生性，一旦删除，只能从备份中找回。建议在动手前用文本编辑器打开一些配置文件，确认里面是否有遗留的自定义数据和重要信息。
跳过逻辑陷阱：识别容易被误判的“大文件”
检查磁盘占用时，会发现有些文件大小惊人，但它们往往不是导致磁盘不足的罪魁祸首。比如系统日志文件会在长时间运行后积累大量内容，这些可以由系统工具自动管理或清空，但务必先确认日志中是否有正在写入的进程，避免清空后引发服务异常。另一类容易被误判的，是来自插件或框架的缓存文件。Hexo插件在运行时会生成缓存，这种缓存通常可以安全清理，但有时插件需要保留缓存来加速构建，删掉后重新生成就会变慢，这属于正常现象，不必紧张。
还有一个常见误解是：认为磁盘空间不足是因为某个文件体积太大，而忽略了文件数量过多的问题。当目录中有海量小文件时，磁盘占用看似不高，但文件节点被耗尽。这种情况下，找到数量最多的目录，删除过期的临时文件和备份文件，比单纯查找大文件更加有效。判断一个目录是否能删，还要看它的最后修改时间以及是否被进程占用。可以用相关命令查看正在打开文件的列表，确认待清理的目录没有被当前运行的服务使用。
小结：带着“备份意识”去清理
安全清理Hexo博客的磁盘空间，核心原则只有一条：先确认文件是否可以重建，再决定是否删除。优先处理依赖和生成文件，这些内容即使误删也能通过命令恢复；谨慎对待源码、配置和用户数据，这类文件一旦丢失，往往就是永久性损失。让清理过程留有回退余地，比“一次清干净”更重要，因为磁盘空间的问题总是暂时的，而辛苦积累的内容一旦丢失，就再也找不回来了。