用 seekg 直接跳转到大文件指定偏移（如 2GB 处）可避免从头扫描，但需 static_cast 防截断、加 std::ios::binary 模式、检查 file.good()，并确认文件大小足够；分割用普通写模式，合并时再用 ios::app。
用 seekg 跳过头部直接读大文件，别用 read 从头扫
大文件（比如几 GB 的日志或二进制数据）如果每次 read 都从开头开始，光定位就要耗几秒。关键是：你往往只关心某一段，比如第 2GB 到 2.5GB 的内容。seekg 就是干这个的——它直接把文件指针挪到指定字节偏移，跳过中间所有字节。
但要注意：seekg 后必须检查是否成功，否则后续 read 可能静默失败：
std::ifstream file("big.bin", std::ios::binary);
file.seekg(2000000000); // 跳到 2GB 处
if (!file.good()) {
// 这里会失败！因为 2000000000 超出 int 范围（32 位平台）
}
- 用
static_cast<:streamoff>(offset)强转，避免隐式截断 - 打开文件时务必加
std::ios::binary，文本模式下seekg行为不可靠 - Windows 上某些 NTFS 卷对 >2GB 偏移支持不稳定，建议先
file.seekg(0, std::ios::end)确认文件大小是否真够
分割时用 std::ofstream 配合 std::ios::app 拼接碎片，但别默认打开就 append
很多人以为 std::ofstream("part_02.bin", std::ios::app) 就能往已有文件末尾写——其实不是。如果文件不存在，app 模式会创建空文件；但如果存在且你想“续写”，必须确保前一次写入已调用 close() 或 flush()，否则缓冲区残留数据可能丢失。
更稳妥的做法是：分割阶段用普通写模式生成独立分片，合并阶段再用 app 拼接：
std::ofstream out("part_01.bin", std::ios::binary); // 不带 app
out.write(buf, chunk_size);
out.close(); // 必须 close，否则下一次 app 打开可能读到旧缓冲
// 合并时才用 app
std::ofstream merged("full.bin", std::ios::binary | std::ios::app);
merged
-
std::ios::app会强制每次写入前 seek 到末尾，频繁小写入性能差，适合合并时一次性追加整个分片 - 不要用
写二进制数据，它会触发格式化（比如把\0当字符串结束），必须用write() - 多个线程并发写不同分片没问题，但合并时绝对不能多线程往同一个
app文件里写——没有原子性保障
跨平台 seekg 偏移超 2GB 的兼容写法
Linux/macOS 默认支持 64 位 off_t，但 Windows 的 MSVC 默认 std::streamoff 是 32 位，导致 seekg(3000000000) 实际变成负数偏移，读出来全是乱码。
解决方案不是换编译器，而是显式使用大整数类型并校验：
constexpr auto offset = static_cast<:streamoff>(3000000000ULL);
file.seekg(offset);
if (file.tellg() != offset) {
// seek 失败：可能是文件太小，或底层不支持
}
</:streamoff>
- 始终用
ULL后缀声明大常量，再强转成std::streamoff -
tellg()返回值也要用std::streamoff接收，别用int或size_t - MinGW-w64 和较新 MSVC（VS2019+）默认启用大文件支持，但老项目可能需要定义
_FILE_OFFSET_BITS=64或_LARGEFILE_SOURCE
合并后校验 MD5 比对原始文件，别信“字节数相等”
分片合并时最隐蔽的坑：某个分片末尾少写了几个字节，但总长度凑巧一样（比如因缓冲未刷盘、write 返回值没检查）。这时候光比 std::filesystem::file_size 没用。
必须做内容级校验：
// 合并完成后立即算 MD5（用 OpenSSL 或 mbedtls）
std::string merged_hash = calc_md5("full.bin");
std::string original_hash = calc_md5("original.bin");
if (merged_hash != original_hash) {
// 分片读取/写入过程有静默截断，重点查最后一个分片的 read() 返回值
}
- 每次
read()都要检查返回值是否等于期望长度，尤其最后一次读，很可能不足整块 - Windows 上用
CreateFile+SetFilePointerEx替代seekg更稳定，但失去跨平台性 - 如果原始文件本身在分割过程中被修改过，MD5 校验必然失败——所以分割前最好先
fsync()或关闭所有写入句柄
事情说清了就结束。真正卡住人的从来不是怎么写，而是 seek 失败不报错、append 时缓冲没清、还有那个永远少读最后 127 字节的 read() 返回值。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
