Buffalo框架不支持断点续传和分片上传，因其默认multipart解析会全量加载文件至内存或磁盘，导致OOM、超时或413错误；必须手动接管Request.Body流、用query传元数据、原子写入分片并校验完整性。

Buffalo 框架本身不提供断点续传或分片上传的内置支持，所有相关逻辑必须手动接管 HTTP body 流、解析 query 元数据、原子写入分片，并自行实现状态校验与合并。直接使用 c.Param("file") 或依赖默认表单解析会触发内存暴涨、超时、413 错误——这不是配置能绕开的问题，是架构层面的限制。

为什么 Buffalo 的默认文件接收不能用于大文件

Buffalo 的 Bind 和 c.Request.MultipartForm 底层调用 Go 标准库 ParseMultipartForm，它会把整个 multipart body 加载进内存（或临时磁盘），对 GB 级文件来说：

• 若 MaxMemory 设得高（如 100MB），单请求吃掉大量 heap，GC 压力陡增，高并发下极易 OOM
• 若设得低（默认 32MB），超出部分落磁盘，但 Buffalo 不暴露 multipart.Reader，你无法流式读取并按需截断
• 没有分片上下文（index、total、md5）的提取通道，所有分片都塞进同一个 file 字段名，后端无法区分
• 无法感知“哪一片已成功写入”，断点续传无从谈起

如何在 Buffalo 中注册纯 body 接收路由

必须禁用 Buffalo 默认的 multipart 解析，在 app.go 的 AppInit 阶段注册拦截器，或直接在 action 内绕过 Bind，用 c.Request.Body 手动读流。

Skill Weave Chains — 技能链路由引擎

开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。

下载

• 路由定义保持简洁：app.Post("/upload/chunk", UploadChunk)，不带任何中间件（尤其禁用 buffalo.PopTransaction 类事务中间件，避免 body 被提前消费）
• 前端必须通过 query 传递元数据：?file_id=abc123&index=5&total=200&md5=def456，不要塞进 form data —— 否则 ParseMultipartForm 会被自动触发
• 在 UploadChunk action 中，先校验 query 参数存在性，再用 io.LimitReader(c.Request.Body, chunkSize) 控制单次读取上限（比如 5MB），防止读爆
• 拒绝使用 c.Request.ParseMultipartForm 或 c.Param("file")，这两者都会导致 body 被二次读取或 panic

分片存储与幂等写入的关键细节

分片不能简单 os.Create 写入，必须确保同一 index 只被写一次，且写入过程不可中断。

• 路径格式建议：/tmp/uploads/{file_id}/{index}，其中 file_id 来自 query，index 是整数，不带扩展名
• 打开文件时务必使用 os.O_CREATE | os.O_WRONLY | os.O_EXCL，靠系统级原子性防止重复写同一片
• 写完立即 os.Chmod(path, 0600)，避免未合并文件被意外读取或遍历
• 写入后调用 os.Sync() 强刷磁盘，否则 crash 或重启可能导致分片内容不完整
• 不要用 defer f.Close() 在写入中途关闭句柄，应显式控制 close 时机

check 接口怎么设计才真正可靠

GET /upload/check?file_id=abc123 必须做两件事：查目录 + 校验文件实体，不能只查数据库记录。

• 列出 /tmp/uploads/abc123/ 下所有文件名，过滤出纯数字命名的条目（如 "0"、"199"）
• 对每个数字文件调用 os.Stat，确认其 size ≥ 预期分片大小（最后一片可略小，但不得为 0）
• 若某文件 size 异常（如 0 字节或远小于预期），视为损坏，不计入 uploaded 列表
• 返回 JSON：{"uploaded":[0,1,2,5,6],"total":200}，前端据此跳过已传分片
• 该接口响应必须快（毫秒级），禁止做 MD5 校验或全量读取——那是合并阶段的事

分片上传真正的难点不在“怎么传”，而在“怎么确认它真的传对了”。哪怕一个字节写偏、一个 os.O_EXCL 忘加、一次 os.Stat 没做，合并时就可能得到损坏文件——而这种错误往往要到用户下载打开时才暴露。