SignalR Hub 无法直接获取上传进度，需前端先建立连接并传递 connectionId，后端通过 IFormFile 流式读取配合 IHubContext 推送进度；须配置请求大小限制、前端正确监听、优化读取缓冲与推送频率。
SignalR Hub 里怎么拿到上传进度
不能直接从 HttpRequest 读取已上传字节数——ASP.NET Core 的默认模型绑定会吃掉整个请求体，等进到 Hub 方法时，数据早没了。得在上传前就建立连接，再用独立的 HTTP 接口（比如 POST /api/upload）边传边发进度，Hub 只负责中转广播。
实操建议：
- 前端先调
connection.start()连上 SignalR Hub，拿到唯一connectionId - 上传请求头里带上这个
connectionId（例如自定义 headerX-Connection-ID） - 后端接收上传时，用
IFormFile配合流式读取，在每次Stream.ReadAsync后计算当前进度，并通过IHubContext<uploadhub>.Clients.Client(connectionId)</uploadhub>推送 - 别用
HttpContext.Request.Body直接读——它和表单解析冲突，会抛InvalidOperationException: Form read already attempted
为什么用 IFormFile 而不是直接读 Request.Body
IFormFile 是 ASP.NET Core 处理 multipart/form-data 的标准抽象，自动处理边界、编码、文件名解码；而手动读 Request.Body 容易卡在 boundary 解析上，尤其当上传带多个字段或中文文件名时，极易出错。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 读到乱码或截断的文件内容
-
Request.Form.Files.Count == 0，但Request.Body明明有数据——其实是模型绑定没触发，因为没走标准 form 解析流程 - 并发上传时出现
InvalidDataException: Multipart body length limit 134217728 exceeded，这是没配MaxRequestBodySize或MultipartBodyLengthLimit
必须配：在 Program.cs 里加 services.Configure<kestrelserveroptions>(options => options.Limits.MaxRequestBodySize = 500_000_000);</kestrelserveroptions> 和 services.Configure<formoptions>(options => options.MultipartBodyLengthLimit = 500_000_000);</formoptions>
HISUI 前端框架基础开发指南。HISUI 是基于 easyui 二次开发的 jQuery UI 组件库，专为医疗信息系统设计。当涉及 HISUI 组件开发、jQuery easyui 表格/表单/布局/窗口、医疗系统前端页面编写时使用此 skill。 涵盖 40 个组件的官方文档参考，支持声明式与编程式两种初始化方式，提供 $cm/$m 数据访问方法。
前端监听不到进度推送？检查这三处
SignalR 连接是“单向”的：Hub 发，客户端收。但很多同学忘了前端要提前注册监听方法，或者 Hub 推送目标错了。
实操要点：
- Hub 里必须用
await Clients.Client(connectionId).SendAsync("UploadProgress", progress)，不是Clients.All——否则所有用户都收到别人上传的进度 - 前端要在
connection.start()成功后，立刻调connection.on("UploadProgress", callback)，顺序反了就收不到首次推送 - Chrome 控制台 Network 标签页里看 SignalR 连接是否为
websocket（而非 long-polling），后者在上传中容易超时断连；可在new HubConnectionBuilder()里加.withUrl("/uploadhub", { transport: HttpTransportType.WebSockets })强制
大文件上传时进度跳变或卡住
不是 SignalR 的问题，是流读取粒度太粗或没做缓冲。每次从 IFormFile.OpenReadStream() 里读 1MB，但网络波动或磁盘慢会导致单次 ReadAsync 耗时几十毫秒，前端看到的就是“0% → 37% → 100%”。
解决办法：
- 把读取 buffer 改小，比如
new byte[65536]（64KB），每读一次就算一次进度并推送 - 加个最小推送间隔（如 200ms 内不重复推），避免高频消息压垮客户端渲染（特别是移动端）
- 别在循环里直接 await
hubContext.Clients...——高频调用会堆积异步任务。改用Task.Run(() => hubContext.Clients...)脱离当前上下文，或攒批（比如每 5% 推一次）
真正难的不是推，是让前端显示平滑。后端算出来的百分比只是“已读字节 / 总长度”，但总长度在 IFormFile.Length 可信的前提是客户端没伪造 content-length——所以生产环境务必校验文件哈希或服务端重算大小。
