c++oding="utf-8" ?>
断点续传需用fstream以ios::in|ios::out|ios::binary模式打开文件，先seekp(offset, ios::beg)精确定位，再写入；tellp()返回-1主因是流未正确打开，务必避免依赖ofstream在非ate模式下的定位能力。
如何用 seekp 定位到文件末尾继续写入
断点续传的核心不是“记住上次位置”，而是“打开文件时精准跳转到已写入的偏移”。seekp 本身不检测文件长度，它只负责定位；你得先知道该跳哪儿，它才敢跳。
常见错误是直接对刚 open 的 ofstream 调用 seekp(0, ios::end) —— 这在大多数标准库实现里会失败（ofstream 默认以 ios::out 模式打开，不支持 seekp 到 end，除非显式加 ios::in 或 ios::ate）。
- 正确做法：用
fstream替代ofstream，并带上ios::in | ios::out | ios::binary - 或改用
ios::ate模式：构造时指定ios::ate，此时文件指针自动置于末尾，再用tellp()获取长度 -
ios::ate的副作用：每次写入前需手动seekp(offset)，否则新内容会追加到末尾而非覆盖/续传
为什么 tellp() 返回 -1？
这是最常卡住的地方：tellp() 在文件未正确定位或流状态异常时返回 -1（即 pos_type(-1)），不是“没长度”，而是“当前不可查”。根本原因通常是流没按需打开。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用
ofstream+ios::ate：可读tellp()，但仅限构造后、首次写入前；一旦写过，某些平台（如 Windows MSVC）可能使tellp()失效 - 用
fstream+ios::in | ios::out | ios::binary：最稳，seekg(0, ios::end); tellg()和seekp(0, ios::end); tellp()都可用 - 别依赖
ofstream::tellp()在非ate模式下返回有效值——它大概率是 0 或 -1
实际续传时怎么避免覆盖或错位
断点续传不是“接着写”，而是“从指定 offset 开始写等长数据”。如果服务端告诉你已收 12345 字节，你就必须把本地文件指针精确设到字节 12345，然后写入剩余部分。错一位，全盘校验失败。
- 务必用
seekp(offset, ios::beg)，别用ios::cur——当前指针位置不可靠（尤其跨平台） - 写入前检查
failbit：if (file.fail()) { /* 清除状态 file.clear(); 再 seekp */ } - 二进制模式（
ios::binary）必须开启，否则 Windows 下换行符 \r\n 会被误算长度 - 写完记得
flush()，否则缓冲区数据可能没落盘，下次续传又从旧位置开始
Windows 与 Linux 下 seekp 行为差异
同一段代码，在 Linux（libstdc++/libc++）下能跑，在 Windows（MSVC）下 seekp 返回 false，大概率是打开模式惹的祸。
- MSVC 的
ofstream对seekp更严格：仅ios::ate或fstreamwithios::in支持定位 - Linux 下部分 libc++ 实现允许
ofstream+ios::out | ios::app后seekp，但这属于非标行为，别依赖 - 统一解法：放弃
ofstream，全部用fstream，且显式传入ios::in | ios::out | ios::binary
真正麻烦的从来不是 seekp 本身，而是你怎么可靠地拿到那个“续传 offset”——它必须来自上一次成功写入后的 tellp() 或系统 stat()，而不是靠猜、靠日志、靠服务端响应头里的模糊字段。只要这个数字不准，后面所有 seekp 都是徒劳。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
