std::filesystem::file_size 是 C++17 起获取文件大小的唯一推荐方式，它不依赖文件打开状态、不修改流位置、不触发 I/O 错误链，且语义清晰——直接查询文件系统元数据。
用 std::filesystem::file_size 最稳，别碰 tellg 读末尾
直接说结论：std::filesystem::file_size 是 C++17 起获取文件大小的唯一推荐方式。它不依赖文件打开状态、不修改流位置、不触发 I/O 错误链，而且语义清晰——就是查元数据。而用 ifstream 配合 seekg(0, std::ios::end); tellg() 看似简单，实则陷阱密布。
常见错误现象：tellg() 返回 -1（表示失败），但你可能没检查；或者文件是二进制但以文本模式打开，导致 Windows 下换行符被误判，tellg 值偏小；再或者文件被其他进程锁住，open() 成功但 seekg 失败，你却当成大小为 0。
- 必须用二进制模式打开流（
std::ios::binary），否则tellg在文本模式下无定义 -
tellg()返回类型是std::streampos，不能直接当size_t用，需转成off_t或uintmax_t再判断是否为 -1 - 即使
open()成功，seekg也可能失败（如只读挂载、NFS 权限抖动），必须检查!ifs.fail()
std::filesystem::file_size 的实际调用要点
它本质是封装了系统调用（Linux 是 stat，Windows 是 GetFileAttributesEx），所以快、准、不碰文件内容。但它不是万能的——路径必须存在且可访问，否则抛 std::filesystem::filesystem_error。
- 路径要传
std::filesystem::path对象，别传裸字符串（否则隐式构造可能失败） - 如果只是想“尝试获取”，别用
try/catch包一层就完事，先用std::filesystem::exists(p)和std::filesystem::is_regular_file(p)做轻量预检 - 返回值是
uintmax_t，不是size_t——大文件（>4GB）在 32 位系统上会截断，务必保持原类型或显式转成off_t
示例：
立即学习“C++免费学习笔记（深入）”；
std::filesystem::path p = "data.bin";
if (std::filesystem::exists(p) && std::filesystem::is_regular_file(p)) {
uintmax_t sz = std::filesystem::file_size(p); // 不抛异常
}
为什么 tellg + seekg 在某些场景下“看起来能用”
它在小文件、本地磁盘、调试环境里常能跑通，是因为：文件未被锁、没跨平台换行、流打开成功、seek 没触发底层权限检查。但这恰恰掩盖了脆弱性——换成容器内挂载的 ConfigMap、Docker volume、或 SMB 共享目录，seekg 就大概率失效。
- POSIX 标准不保证所有文件系统支持
seek到末尾（比如 /proc 下的伪文件、管道、socket） - C++ 标准只规定
tellg在“可定位流”上有效，而是否可定位由实现和 OS 共同决定，不可移植 - 哪怕成功，也要多一次系统调用（open → seek → tellg → close），比单次
stat多开销
兼容旧标准（C++11/14）时的折中方案
如果真不能用 std::filesystem，别硬写 tellg，改用 POSIX stat 或 Windows GetFileSizeEx。C++11 本身不提供跨平台方案，强行用流模拟只会放大问题。
- Linux/macOS：用
struct stat st; if (stat(path.c_str(), &st) == 0) sz = st.st_size; - Windows：用
WIN32_FILE_ATTRIBUTE_DATA attr; if (GetFileAttributesEx(path.c_str(), GetFileExInfoStandard, &attr)) { sz = ((uint64_t)attr.nFileSizeHigh - 不要用
fopen+fseek+ftell—— 同样有文本/二进制歧义，且 C 风格 API 更难做错误分支处理
真正容易被忽略的点：文件大小可能在两次调用间变化（尤其是日志文件、网络文件系统），file_size 和 stat 都只反映调用瞬间的状态，别把它当文件锁用。
