使用Stream.Position追踪MinIO上传进度是否会引发问题

多文件拖拽导致Blazor电路断开的问题 #

你选择的「超过150个文件强制传压缩包」的方案是完全可行的。
这个问题的根因是Blazor Server的文件上传走SignalR信道，默认对单条消息大小、电路缓冲区都有阈值限制，200个以上文件的元数据（文件名、大小、类型等信息）一次性打包回传时，很容易触发阈值被服务端主动断开电路。相比修改全局SignalR消息上限这种可能放大服务器资源风险的操作，你设150的阈值留了足够冗余，是成本最低、最稳妥的解法。

监控MinIO上传进度的方案问题 #

你测试时用轮询dataStream.Position的方式能看到数值增长，但这个方案有几个明确的缺陷，不适合直接用到生产环境：

• 线程安全风险：Stream的Position属性本身不保证线程安全，MinIO客户端内部读流的线程和你开的轮询线程同时访问该属性时，遇到非内存缓冲流（比如大文件的分段流、加密流）会出现数值错乱、甚至随机抛异常的问题，后续如果开分块上传，Position还可能出现跳变，进度条会来回跳。
• 进度虚高：你观测到的Position增长，仅代表MinIO客户端把流数据读到了自身的发送缓冲区，不代表数据已经发送到MinIO服务端、更不代表服务端已经接收落盘。遇到网络卡顿、发送缓冲区阻塞时，会出现进度条早就到100%，实际上传卡了一半的情况，用户体验反而更差。
• 异常感知缺失：你的轮询逻辑只判断Position是否到达文件总大小，如果上传中途抛出网络错误、权限错误、存储桶不存在等异常，轮询任务不会主动终止，会一直空转直到超时，平白占用线程资源。
• Blazor线程适配问题：你当前只做了控制台输出，实际要更新UI时，轮询逻辑跑在线程池线程上，直接修改组件状态会触发Blazor的跨线程访问异常，必须每次更新都切回UI同步上下文，增加了不必要的复杂度。

更稳妥的实现方式 #

MinIO .NET客户端原生就支持进度上报，不需要自己轮询流位置，调用WithProgress方法传入标准的IProgress<long>实例即可，客户端每确认一块数据发送成功就会触发回调，上报的是已经实际发送到服务端的字节数，进度准确也没有线程安全问题。
参考实现代码：

public async Task StoreFile(ImageDatabaseModel image, Stream dataStream, string contentType, long fileSize, IProgress<long> uploadProgress = null)
{
    await CreateBucketIfNotExists(image.UserID);
    PutObjectArgs args = new PutObjectArgs()
        .WithBucket(image.UserID)
        .WithObject(GetMinioImageName(image))
        .WithStreamData(dataStream)
        .WithContentType(contentType)
        .WithObjectSize(fileSize);

    // 注册进度回调
    if (uploadProgress != null)
    {
        args = args.WithProgress(uploadProgress);
    }

    await _minio.PutObjectAsync(args);
}

在Blazor组件中调用时，创建Progress<long>实例，在回调里计算上传百分比、更新UI状态即可，不需要额外开轮询任务。如果是GB级的大压缩包上传，建议开启分块上传，不仅稳定性更高，进度上报的频率也更均匀，不会出现进度卡半天突然跳一大截的问题。

内容的提问来源于stack exchange，提问作者Roland Deschain