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 手动读流。
- 路由定义保持简洁：
app.Post("/upload/chunk", UploadChunk)，不带任何中间件（尤其禁用buffalo.PopTransaction类事务中间件，避免 body 被提前消费） - 前端必须通过 query 传递元数据：
?file_id=abc123&index=5&total=200&md5=def456，不要塞进 form data —— 否则ParseMultipartForm会被自动触发 - 在
UploadChunkaction 中，先校验 query 参数存在性，再用io.LimitReader(c.Request.Body, chunkSize)控制单次读取上限（比如 5MB），防止读爆 - 拒绝使用
c.Request.ParseMultipartForm或c.Param("file")，这两者都会导致 body 被二次读取或 panic
分片存储与幂等写入的关键细节
分片不能简单 os.Create 写入，必须确保同一 index 只被写一次，且写入过程不可中断。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 路径格式建议：
/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 没做，合并时就可能得到损坏文件——而这种错误往往要到用户下载打开时才暴露。
