不能直接用 std::ifstream::tellg() 驱动 UI 进度条，因其在循环读取中常返回 -1 或不准；应改用 read() 分块读取并手动累加 done，以 file.gcount() 为准，配合回调实现精确、可中断的进度更新。
不能直接用 std::ifstream 获取已读字节数来驱动 UI 进度条——它不提供实时读取偏移，必须自己控制读取节奏并手动累计。
为什么 std::ifstream::tellg() 在循环读取中常返回 -1 或不准
这是最常见的卡点：在未明确调用 seekg() 或文件流处于错误/EOF 状态时，tellg() 返回 -1；即使正常，某些平台（尤其是 Windows 下带 BOM 的文本文件）或使用 std::ios::binary 以外模式时，tellg() 可能因换行符转换、缓冲区未刷新而滞后于实际读取量。
- 只在打开后、首次读取前和每次
seekg()后调用tellg()才可靠 - 文本模式下，
\r\n → \n转换会导致字节级偏移与逻辑行数错位 - 真正可控的方式是：用固定缓冲区
read()，自己累加已读字节数
用 std::istream::read() + 回调实现可中断的进度更新
核心是放弃“自动流式读取”，改为主动分块拉取，并在每块读完后触发回调。这样既能精确计数，又能响应取消信号（如用户点击“停止”）。
void readFileWithProgress(const std::string& path,
std::function<void(size_t done, size_t total)> onProgress) {
std::ifstream file(path, std::ios::binary);
if (!file.is_open()) return;
<pre class='brush:php;toolbar:false;'>file.seekg(0, std::ios::end);
size_t total = static_cast<size_t>(file.tellg());
file.seekg(0, std::ios::beg);
std::vector<char> buf(8192); // 8KB 缓冲区，兼顾性能与响应性
size_t done = 0;
while (file.good() && !file.eof()) {
file.read(buf.data(), buf.size());
size_t readNow = static_cast<size_t>(file.gcount());
done += readNow;
onProgress(done, total);
// 检查是否被外部中断（例如 Qt 中检查 QThread::isInterruptionRequested）
if (/* 中断条件 */) break;
}}
立即学习“C++免费学习笔记（深入）”；
-
file.gcount()是唯一可信的本次实际读取字节数，read()即使只读到部分也如实返回 - 缓冲区大小不宜过大（>64KB），否则 UI 更新延迟明显；也不宜过小（
- 务必用
std::ios::binary打开，避免文本模式干扰字节计数
Qt 场景下绑定到 QProgressBar 的典型陷阱
Qt 的事件循环与文件 I/O 不兼容：若在主线程同步读文件，UI 会完全冻结，进度条卡死不动；若用 QThread，又不能直接操作主线程控件。
- 绝不在主线程调用阻塞式
readFileWithProgress()—— 即使加了回调，UI 仍无响应 - 正确做法：子线程执行读取，通过
QMetaObject::invokeMethod()或信号槽（需Qt::QueuedConnection）安全更新QProgressBar::setValue() - 注意
QProgressBar::setMaximum()必须在知道total后立即设置，且只能设一次；重复设可能重置动画状态 - 若文件极大（>2GB），
size_t在 32 位环境可能溢出，建议用std::uint64_t存 total/done
真正的难点不在计算进度，而在把“字节流”和“UI 生命周期”解耦——缓冲区大小、回调频率、线程切换时机、中断响应粒度，每个都影响用户体验。别迷信 tellg()，老老实实自己算。
