Iris框架本身不内置断点续传逻辑，但可通过正确处理HTTP Range请求头、Content-Range响应头、206状态码及文件系统操作实现服务端支持，需避免文件锁、并发读、路径遍历等风险。
Iris 框架本身不内置断点续传逻辑，但可以基于 HTTP Range 请求头 + 文件系统操作完整实现服务端支持。关键不是“用 Iris 能不能做”，而是你是否正确处理了 Range、If-Range、Content-Range 和 206 状态码，同时避免踩文件锁、并发读、路径遍历等坑。
怎么判断客户端发来了断点续传请求
客户端发起断点续传时，一定会在请求头里带上 Range，比如 Range: bytes=1024-2047。Iris 的 ctx.Request().Header.Get("Range") 可以拿到原始值。注意：Range 不是必选头，没有它就按普通 200 下载处理；有但格式非法（如 bytes=- 或负数起始）应返回 416；有且合法才走 206 分片逻辑。
常见错误现象：
- 直接忽略
Range头，始终返回 200 + 全量文件 → 客户端收不到分片响应，断点失败 - 没校验
Range范围是否超出文件大小 → 返回 206 但内容长度不对，客户端解析崩溃 - 没检查
If-Range头（含 ETag 或 Last-Modified）→ 无法应对文件被修改后继续续传的场景
怎么用 Iris 返回 206 Partial Content 响应
Iris 提供 ctx.Response().Writer().WriteHeader(206) 和手动写 header 的能力，但更稳妥的是封装一个复用函数，统一设置 Content-Range、Accept-Ranges、Content-Length 和响应体。不要用 ctx.ServeFile() —— 它不识别 Range，永远走 200。
实操要点：
-
Content-Range格式必须为bytes START-END/TOTAL，例如bytes 1024-2047/1048576 - 响应体必须只包含指定字节范围的数据，多一个字节或少一个字节都会导致客户端校验失败
- 务必设置
ctx.ResponseWriter().Header().Set("Accept-Ranges", "bytes")，否则某些客户端（如 curl -C）不会尝试续传 - 用
io.CopyN或file.ReadAt精确读取，避免把整个文件 load 到内存
怎么安全地读取大文件的指定区间
别用 os.Open 后 io.ReadAll 再切片 —— 这会 OOM。正确做法是打开文件后调用 file.ReadAt(buf, offset)，其中 offset 来自 Range 解析结果。注意文件必须以只读方式打开，且不能被其他进程写入（否则读到脏数据）。
容易踩的坑：
- 没检查文件是否存在或是否有读权限 → 返回 500 而非 404/403
- 没用
defer file.Close()→ 文件句柄泄漏，Linux 下很快 hit ulimit - 用
os.Stat获取文件大小后，没在读取前再次确认文件未被截断或替换 →ReadAt可能返回io.EOF，需映射为 416 - 路径拼接未做白名单校验或
filepath.Clean→ 攻击者构造../../etc/passwd触发任意文件读取
要不要加上传断点续传支持
Iris 作为服务端框架，不处理上传断点续传的协议细节（那是客户端和反向代理的事）。如果你要支持上传断点，得自己设计状态存储（如 Redis 记录已收块、MD5、总大小），并暴露类似 /upload/resume 的接口供客户端轮询或提交新块。这和下载断点是两套逻辑，别混为一谈。
现实中最常被忽略的一点：浏览器原生 fetch 或 XMLHttpRequest 不支持上传断点；所谓“断点上传”基本都依赖客户端 SDK（如 tus.io 协议）或自定义分片上传逻辑。Iris 只需提供稳定接收单个分片的能力，并确保幂等性（同一分片重复提交不破坏状态）。
