用libcurl发起带range头的http请求需调用curl_easy_setopt(handle, curlopt_range, "start-end")，并检查响应状态码206和content-range头；写入文件须用r+b模式配合fseek/lseek定位偏移，多线程需同步写入或统一由主线程顺序写入。
怎么用 C++ 发起带 Range 头的 HTTP 请求
核心是让 HTTP 客户端在请求时带上 Range: bytes=xxx-，告诉服务器只下载文件某一段。C++ 本身没内置 HTTP 客户端，得靠第三方库——libcurl 是最稳的选择，比手写 socket 或硬啃 Boost.Beast 实际得多。
常见错误是直接拼接 URL 加参数（比如 ?start=1024），这根本不是断点续传；也有人误以为设置 Content-Range 是客户端该干的事，其实那是服务器返回的响应头，客户端只管发 Range。
-
curl_easy_setopt(handle, CURLOPT_RANGE, "1024-2047")是最直接的方式，字符串格式必须是"start-end"或"start-"（后者表示从 start 到末尾） - 别漏掉
curl_easy_setopt(handle, CURLOPT_HEADERFUNCTION, ...)，否则你看不到响应里的Content-Range和206 Partial Content，没法验证是否真走通了断点逻辑 - 如果服务器不支持
Range（比如某些静态文件托管服务默认关掉），会返回200 OK+ 全量内容，且无Content-Range头——这是你程序里必须检查的失败信号
如何把接收到的数据写到文件指定偏移位置
拿到分段数据后，不能简单用 fopen(..., "ab") 追加写，否则多段并发或重试时顺序错乱。必须用 fseek 或 lseek 定位，再用 fwrite / write 写入，确保每段落在它该在的位置。
Windows 下用 fseek 没问题；Linux/macOS 下推荐用 lseek + write，避免 stdio 缓冲干扰，尤其大文件写入更可控。
- 打开文件必须用
"r+b"（二进制读写），不能用"w"或"a"，否则清空或强制追加 - 写之前先
lseek(fd, offset, SEEK_SET)，offset 就是这段数据本该落盘的字节起点，比如第二段从 1024 开始，就 seek 到 1024 - 写完要检查
write返回值是否等于预期长度，网络中断或磁盘满会导致短写，这时得记下实际写了多少，下次续传从那里开始
怎么判断断点是否真正生效：看响应头和状态码
光发了 Range 不代表服务器照做。关键看响应：状态码必须是 206 Partial Content，且响应头里必须有 Content-Range，格式类似 bytes 1024-2047/1048576。缺一不可。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
容易被忽略的是：有些代理或 CDN 会把 206 悄悄转成 200，或者吞掉 Content-Range。所以不能只信状态码，得同时校验响应头。
- 用
curl_easy_setopt(handle, CURLOPT_HEADERDATA, &header_buf)把响应头存下来，之后用strstr查"HTTP/1.1 206"和"Content-Range:" - 如果收到
200但Content-Length小于整个文件大小，大概率是服务器不支持 Range 却返回了截断内容——这种响应不可信，应中止续传 - 注意
Content-Range中的总长（/1048576那部分）是否和你已知的文件大小一致，不一致说明服务端文件可能被更新过，得重新获取HEAD确认
多线程并发下载同一文件的分段时要注意什么
可以并发，但文件写入必须串行或加锁。多个线程同时 lseek + write 到不同 offset 理论上安全，但实际中 glibc 的 write 在某些文件系统上可能有缓存竞争，导致写花。
更稳妥的做法是每个线程把数据暂存内存或临时 buffer，下载完统一由主线程按 offset 顺序写入。牺牲一点内存，换确定性。
- 不要让多个线程共用同一个
FILE*或 fd，即使只读也不建议；每个线程自己open同一个文件（O_RDWR）是可以的，但写入仍需同步 - 如果用
mmap映射文件再 memcpy，必须确保映射区域足够大且提前ftruncate到最终大小，否则写越界会触发SIGBUS - 并发数不是越多越好，HTTP/1.1 连接复用有限，太多并发反而触发服务器限速或连接拒绝；一般 3–5 个连接比较现实
断点续传真正的复杂点不在发请求，而在状态持久化：每次崩溃后，你得准确知道哪几段已写、哪几段写了一半、哪几段根本没发。这些信息不能只存在内存里，得落地到本地小文件或数据库，而且写入时机要卡在数据落盘之后、更新状态之前——这个顺序一旦颠倒，就永远对不上了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
