AList项目大文件拷贝内存暴增问题分析与解决方案

问题背景

在AList项目v3.35.0版本中，用户发现当从本地存储(Local)向其他AList v3存储拷贝大文件时，会出现内存占用急剧增加的现象，严重时甚至导致进程崩溃。这一问题在内存较小的设备上尤为明显，如Android设备和Docker容器等。

问题现象

具体表现为：

1. 执行大文件拷贝操作时，内存占用迅速增长
2. 内存增长幅度可能超过正在拷贝的文件大小
3. 在内存受限的设备上会导致进程崩溃，拷贝失败

技术分析

经过深入排查，发现问题根源在于AList v3驱动使用了go-resty/resty库来实现文件上传功能。该库为了实现重试机制，会对io.Reader类型的数据进行缓存，具体体现在其middleware.go文件的第490行代码处。

当执行到缓存操作时，内存使用量会急剧上升。这是因为go-resty/resty为了支持上传失败后的重试，需要将整个文件内容缓存在内存中，对于大文件来说，这显然会带来严重的内存压力。

解决方案探讨

目前提出了两种可行的解决方案：

1. 改用标准库net/http：

   • 优点：直接使用Go语言自带的net/http库，不会产生额外的内存缓存
   • 缺点：不支持自动重试机制，需要自行实现重试逻辑

2. 继续使用go-resty/resty但改为分片上传：

   • 优点：保留现有的重试机制
   • 缺点：需要AList服务端支持分片上传功能

从技术实现角度来看，第一种方案更为简单直接，能够立即解决内存暴增的问题。虽然会失去自动重试功能，但对于大文件传输场景，分片上传可能是更合理的解决方案。

实际验证

开发者已经对第一种方案进行了验证：

• 改用标准net/http库后，内存使用保持稳定
• 大文件传输过程中不再出现内存暴增现象
• 传输功能正常，验证了方案的可行性

总结与建议

对于AList项目的大文件传输功能，建议采取以下改进措施：

1. 短期方案：优先采用标准net/http库替代go-resty/resty，解决内存问题
2. 长期方案：实现分片上传功能，既解决内存问题又保留重试机制
3. 对于内存受限设备，建议默认启用分片传输模式

这一问题的解决将显著提升AList在大文件处理方面的稳定性和可靠性，特别是在资源受限环境下的表现。