核心是用r将光标移至行首实现覆盖刷新；需注意旧内容长度，避免残留，可通过补空格或固定宽度格式化解决。
用 r 覆盖当前行实现进度刷新
终端里不换行、只更新同一行内容，核心就靠回车符 r —— 它把光标移回行首，后续输出覆盖原内容。别用 n，否则每行都堆一个新进度条，根本不是“动态”效果。
常见错误是忘了清空旧内容长度：比如上一次显示 "5%"（2 字符），下一次显示 "100%"（4 字符），但没补空格，结果变成 "100%0%"。解决方法是在每次打印后手动填充空格再 r，或者用固定宽度格式化。
- 用
std::cout 强制刷新缓冲区，否则可能卡住不显示 - Windows 控制台对
r支持稳定，Linux/macOS 也完全没问题 - 避免混用
std::endl（它等价于n + flush），会强制换行破坏覆盖逻辑
std::setw 和 std::setfill 控制对齐与补空
百分比数字位数变化时，光靠 r 不够，得让输出总宽度一致，否则残留字符会干扰视觉。c++ 的 iomanip 提供了轻量方案。
典型场景：进度从 1% 到 100%，你希望它们都在同一位置右对齐，且整行宽度固定为 10 字符（含 % 和空格）。这时候 std::setw 搭配 std::setfill(' ') 就很直接。
立即学习“C++免费学习笔记（深入）”；
- 必须每次输出前重设
std::setw，它不持久；std::setfill设置后会保持，但建议每次显式调用更稳妥 - 别写
std::cout 然后直接 <code>r——如果i是7，实际占 2 字符，剩下 3 个空格不会自动覆盖右侧旧内容，得自己补 - 更可靠做法：先输出固定宽度字符串（如用
std::to_string+ 手动补空），再整体r
避免频繁 I/O 拖慢主线程
每 1% 就刷一次屏幕？在循环里调用几十次 std::cout，性能其实不差，但若进度更新极快（比如处理 GB 级文件），频繁刷屏反而成瓶颈，还可能触发终端渲染抖动。
真实使用中，没人需要每 0.1% 都看见——人眼根本反应不过来。关键在于「按需采样」，而不是「按计算步长」。
- 记录上一次显示的整数百分比（如
last_shown = -1），每次算出current = (i * 100) / total，仅当current != last_shown时才输出 - 如果
total很小（比如只有 10 步），直接每步刷一次也没问题；但若total是百万级，这个判断能减少 99% 的 I/O - 不要用
std::this_thread::sleep_for来“限速”，那会拖慢整个任务；采样逻辑本身开销几乎为零
Windows 下 SetConsoleCursorPosition 不是必需的
网上有些例子用 WinAPI 的 SetConsoleCursorPosition 去定位光标，其实纯属过度设计。只要不用 n、不触发换行、不被其他日志打断，r 就足够干净可靠。
引入平台 API 会破坏跨平台性，而且增加编译条件和错误处理负担。除非你在做复杂多行进度（如并行任务各自一行），否则没必要。
- MinGW、MSVC、Clang on Windows 都支持
r行为，无需额外配置 - 如果程序同时输出错误日志（比如
std::cerr），注意它默认不带缓冲，可能插在进度行中间，导致错乱；可临时重定向或加锁 - 最简健壮组合就是：
r+ 固定宽度字符串 +std::flush
真正容易被忽略的是缓冲区同步时机和残留字符清理——尤其当进度提前结束（比如用户 Ctrl+C）时，最后一行可能停在 "98%"，而主程序已退出，终端还留着半截状态。这种边界情况不常测，但上线后会被用户截图发到群里问“为啥卡住了”。