用fseek+ftell可稳定估算文件读写进度：先以二进制模式打开文件，fseek(fp,0,SEEK_END)获取总大小，再循环读写块并用ftell实时获取当前偏移量计算百分比；需避免文本模式换行符干扰、流状态异常导致tellg失效，大文件应优先用stat.st_size或GetFileSizeEx。
用 fseek + ftell 配合循环读取实现进度估算
纯 C++ 标准库（std::ifstream/std::ofstream）本身不提供文件读写进度回调机制，必须手动计算。核心思路是：先获取文件总大小，再在每次读/写块后，用当前偏移量除以总大小得出百分比。C 风格的 fseek 和 ftell 在二进制模式下更稳定，尤其对大文件或非 seekable 流要格外小心——但普通磁盘文件完全适用。
常见错误是直接对 std::ifstream 调用 tellg() 后立刻读取，却没注意：未调用 clear() 或未确保流状态正常时，tellg() 可能返回 -1；或者在文本模式下读取换行符导致偏移量与字节数不一致。
- 务必用
std::ios::binary打开文件，避免 Windows 下\r\n被转换干扰字节计数 - 用
fseek(fp, 0, SEEK_END); total = ftell(fp); fseek(fp, 0, SEEK_SET);获取总字节数，比std::filesystem::file_size更早兼容旧编译器（如 GCC 7 以下） - 每次
fread或read后立即调用ftell，不要依赖累计变量——防止因部分读失败导致进度跳变
用 std::ifstream::read + std::ifstream::tellg 的安全写法
如果坚持用 C++ 流接口，关键在于控制流状态和同步时机。很多开发者发现 tellg() 返回值“不准”，其实是因为读操作出错（比如 EOF 提前触发、缓冲区未刷新）后流进入 failbit 状态，后续 tellg() 直接失效。
使用场景：小到中等文件（
立即学习“C++免费学习笔记（深入）”；
- 打开后立刻检查
if (!ifs) return;，并用ifs.clear();清除可能的初始错误标志 - 读取前调用
ifs.clear();，读取后立即auto pos = ifs.tellg();，再判断pos == -1就跳过本次回调 - 避免在循环内频繁调用
tellg()——它底层仍会触发系统调用，可改为每读 N KB（如 64KB）再算一次进度，减少开销
回调函数设计要避开线程与生命周期陷阱
进度回调看似简单，实际最容易崩在多线程和对象生命周期上。典型错误：把 lambda 捕获了局部 std::string 或 this 指针传给后台线程，结果主线程函数退出后回调还在访问已析构内存。
参数差异直接影响安全性：std::function<void></void> 比裸函数指针更灵活，但拷贝成本略高；若回调只用于 UI 更新（如 Qt 的 QProgressBar::setValue），必须确保调用发生在主线程。
- 回调函数签名建议统一为
void(*)(int percent)或std::function<void></void>，避免传递浮点或字符串——整数百分比足够，且无精度/编码问题 - 如果读写在子线程执行，回调里禁止直接操作 UI 控件；Qt 用户用
QMetaObject::invokeMethod，Win32 用PostMessage，跨平台可用std::queue+ 主循环轮询 - 不要把回调对象（如
std::shared_ptr<progresstracker></progresstracker>）绑定到异步读写函数内部——应由调用方持有并确保其生命周期长于读写过程
大文件（>4GB）和 mmap 场景下的进度偏差处理
当文件超过 4GB，在 32 位环境或某些老 libc 上，ftell 可能截断高位，返回负值或错误值；而 mmap 方式下，off_t 和映射地址偏移的对应关系也容易误算。此时不能简单用 “当前地址 - 起始地址” 除以 “文件大小”。
性能影响明显：mmap 本可避免多次系统调用，但如果每次回调都重新计算偏移，反而抵消优势。关键是把进度计算逻辑从热路径中剥离。
- Linux/macOS 下优先用
stat.st_size（struct stat中的off_t st_size），它天然支持大文件；Windows 用GetFileSizeEx - 若用
mmap，记录mmap返回的起始地址和文件大小，进度 =(current_ptr - map_start) * 100 / file_size，但current_ptr必须是按块推进的真实处理位置，而非虚拟内存地址任意取值 - 对超大文件（如 100GB 视频），用户感知的“进度”其实不需要精确到 0.001%，可做阶梯式上报：每完成 1% 才触发一次回调，避免 UI 频繁重绘卡顿
进度回调真正难的不是算百分比，而是保证那个百分比数字背后的状态始终可信——它依赖文件大小获取的时机、读写单位的一致性、以及回调上下文的生存期。别让一个看似辅助的功能，变成崩溃的入口。
