用std::ifstream和std::ofstream逐块读写最稳妥，需以binary模式打开、控制块大小（如64KB）、每次read后用gcount()获取真实字节数、检查流状态，避免截断或重复。
大文件合并：用 std::ifstream 和 std::ofstream 逐块读写最稳妥
直接用 std::ios::binary 模式打开文件，避免文本换行符干扰和缓冲区截断。关键不是“一次读完”，而是控制块大小——64KB 是多数系统下兼顾性能与内存安全的折中值（太小导致 syscall 过多，太大可能在嵌入式或低内存环境触发 bad_alloc）。
常见错误是忘记检查 read() 实际读取字节数，导致末尾数据重复或丢失；也有人误用 gcount() 前不调 clear()，在 EOF 后仍返回上一次计数。
- 每次
read()后必须调用in.gcount()获取真实读取长度，而非假设等于缓冲区大小 - 写入前检查
out.good()，尤其在循环中——磁盘满、权限丢失等错误不会立刻抛异常，但会置位failbit - 不要用
in >> buffer或getline()处理二进制数据，它们会提前终止于
std::ifstream in("part_001.bin", std::ios::binary);
std::ofstream out("merged.dat", std::ios::binary);
char buf[65536];
while (in.read(buf, sizeof(buf))) {
out.write(buf, in.gcount());
}
if (in.gcount() > 0) { // 处理最后一块不足 64KB 的情况
out.write(buf, in.gcount());
}
按固定大小拆分：注意边界对齐和文件名序号格式
拆分的核心陷阱不在读写逻辑，而在文件命名与大小精度。比如指定“每片 10MB”，但原始文件大小为 32.7MB，最后一个小文件只有 2.7MB —— 如果硬编码文件名用 part_001 到 part_003，就必须确保序号严格补零且可排序，否则 ls 或后续合并时顺序错乱。
另一个常被忽略的是：不能简单用 file_size / chunk_size 算总片数，必须用 (file_size + chunk_size - 1) / chunk_size 向上取整，否则 1B 文件在 1MB 分片下会算出 0 片。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 使用
std::filesystem::file_size()（C++17）获取准确大小，避免stat()手动结构体解析 - 生成文件名时用
std::format("part_{:03d}.bin", index)（C++20）或sprintf补零，禁用"part_" + std::to_string(i) + ".bin"—— 它无法保证字典序正确 - 拆分时最后一块的
read()可能返回少于请求字节数，此时必须按gcount()写入，不可补零填充（否则破坏原始数据）
校验与容错：为什么 md5sum 不适合做合并后验证
MD5 碰撞虽概率极低，但工具级校验更应关注可复现性与调试友好性。对大文件全程计算 MD5 会显著拖慢流程，且一旦失败无法定位是哪一片出错。实际工程中推荐两级策略：拆分时为每个分片生成独立 SHA-256，并记录到元数据文件；合并后只比对最终文件的 SHA-256 与原始值。
- 不要在合并过程中实时计算整个输出文件的哈希——IO 和 CPU 串行化，性能损失明显
- 元数据文件（如
manifest.json）应包含每片的偏移量、大小、哈希，方便跳过损坏分片重试 - 若需快速验证完整性，可用
std::hash<:string_view></:string_view>做轻量级 checksum（仅限开发自测），但生产环境必须用加密哈希
跨平台路径与权限：Windows 下 \? 前缀和 Linux 的 O_LARGEFILE
Windows 对长路径（>260 字符）默认拒绝访问，即使你用了 std::filesystem。必须在路径前加 \? 前缀才能绕过限制；而 Linux 下若未定义 _FILE_OFFSET_BITS=64，32 位程序可能无法处理 >2GB 的文件（lseek 返回 -1，errno=EOVERFLOW）。
- Windows：构造路径时判断是否启用长路径支持，必要时用
R"(\?)" + path.string() - Linux/macOS：编译时加
-D_FILE_OFFSET_BITS=64，并确认off_t是 64 位（可用static_assert(sizeof(off_t) == 8)防御） - 所有 open 操作后立即检查
is_open()，不要依赖后续读写失败再报错——有些系统（如某些 NFS）延迟暴露权限问题
真正难的不是读写本身，是让工具在 2TB 文件、中文路径、U 盘热拔插、磁盘突然只读这些现实场景里不静默失败。每一块逻辑都要有明确的失败出口和可追溯的上下文信息，而不是靠“应该没问题”推进。
