DigitalOcean Droplet空间耗尽，Laravel 7.3应用崩溃解决方案咨询

一、存储卷挂载方案的价值 #

存储卷挂载是低成本、针对性扩容的优质方案，适合不想整体升级Droplet、仅特定目录占用大量空间的场景，能快速解决空间耗尽问题，且不影响现有应用架构，是当前场景下的可行选项之一。

优先挂载的Laravel目录 #

根据Laravel的空间占用特性，按优先级排序：

• storage/app/public：用户上传的图片、文档等静态文件几乎都会存在这里，是绝大多数Laravel应用的空间大户，优先挂载存储卷。
• storage/logs：若开启了详细日志级别，长期运行后日志文件会持续膨胀；如果日志量极大，可挂载到存储卷（也可配合日志轮转方案减少占用）。
• 自定义业务存储目录：如果你的应用有生成报表、备份文件等自定义存储路径，需检查其占用空间，按需挂载。
• vendor：依赖包目录体积不小，但不会持续增长，除非频繁更新依赖，优先级低于前三者。

挂载操作注意事项 #

1. 先备份目标目录的所有文件，避免挂载后数据丢失。
2. 创建存储卷后，先临时挂载到一个过渡目录（比如/mnt/temp），将原目录文件复制到该过渡目录，再卸载临时挂载，重新挂载到目标Laravel目录。
3. 编辑/etc/fstab添加挂载规则时，使用存储卷的UUID或块设备路径，添加defaults,nofail参数，确保系统启动自动挂载，且挂载失败不影响系统启动。示例配置：

   /dev/disk/by-id/scsi-0DO_Volume_your-volume-name /var/www/laravel/storage/app/public ext4 defaults,nofail 0 0
   

4. 挂载完成后，调整目录权限，确保Web服务和PHP进程有读写权限：

   chown -R www-data:www-data /var/www/laravel/storage/app/public
   

二、其他可行解决方案 #

紧急清理（快速恢复应用） #

先通过清理释放空间，让应用恢复运行：

• 清空Laravel日志：truncate -s 0 storage/logs/*.log，同时建议配置日志轮转（新建/etc/logrotate.d/laravel，设置定期压缩、删除旧日志）。
• 清理Composer缓存：composer clear-cache。
• 清理系统冗余文件：Debian/Ubuntu系统执行apt autoremove && apt clean；CentOS执行yum clean all。
• 删除无用文件：比如旧备份、未使用的用户上传文件、过期的临时文件。

直接升级Droplet磁盘 #

如果整个Droplet的磁盘空间都紧张，而非单个目录，直接升级Droplet的磁盘容量是更省心的方案——DigitalOcean支持在线升级，无需重新部署应用，升级后扩展文件系统即可使用新增空间。

对象存储替代静态文件 #

若用户上传的静态文件是主要空间占用源，可迁移到DigitalOcean Spaces（兼容S3协议的对象存储）：

• 修改Laravel的config/filesystems.php，配置s3驱动指向Spaces。
• 将现有storage/app/public的文件同步到Spaces，之后应用的文件读写都直接走对象存储，彻底解放Droplet本地空间，还能配合CDN加速文件访问。

日志集中管理 #

将Laravel日志发送到外部日志服务（比如自建ELK Stack，或使用托管日志服务），避免本地日志持续占用空间，同时更便于日志分析和留存。

内容的提问来源于stack exchange，提问作者mr. d3v