正确做法是用 ifstream/ofstream 配合固定大小缓冲区（如8192）循环读写，检查 read() 实际读取字节数，切片命名用定宽序号（如slice_0001.bin），合并前排序文件名并校验SHA-256。
用 fstream 按固定大小切分大文件，别直接 read() 到 std::string
大文件（比如几百 MB 的二维码二进制流）切片时，常见错误是把整块数据读进 std::string 或 std::vector<char></char> 再写入子文件——内存爆掉或性能骤降。正确做法是用 std::ifstream 和 std::ofstream 配合缓冲区循环读写，不加载全文到内存。
关键点：
-
read()返回值必须检查：它可能少于请求字节数（尤其接近 EOF 时），不能假设“调用一次就满 - 缓冲区大小建议设为 8192 或 65536（2 的幂），避开磁盘页边界问题
- 切片命名推荐带序号和总片数，如
data_0001_of_0012.bin，方便合并时排序
std::ifstream src("qrcode.bin", std::ios::binary);
char buf[8192];
int slice_idx = 0, slice_size = 1024 * 1024; // 1MB per slice
while (src.good()) {
src.read(buf, sizeof(buf));
size_t n = src.gcount();
if (n == 0) break;
<pre class="brush:php;toolbar:false;">std::ofstream dst("slice_" + std::to_string(++slice_idx) + ".bin", std::ios::binary);
dst.write(buf, n);
dst.close();}
合并时按文件名自然序读取，别依赖 readdir() 返回顺序
Linux/macOS 下 readdir() 不保证文件名有序；Windows 的 FindFirstFile 同样不可靠。如果切片文件名是 slice_1.bin、slice_10.bin、slice_2.bin，直接遍历目录会先读 1、再 10、再 2，导致二进制流错乱。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 切片时强制用定宽数字命名（如
slice_0001.bin），位数根据总片数预估 - 合并前用
std::vector<:string></:string>收集所有匹配文件名，再用std::sort排序（基于字符串本身即可，因已定宽） - 不要用
std::filesystem::directory_iterator边遍历边合并——C++17 标准不保证顺序，且部分旧编译器没实现
二维码二进制流对完整性极度敏感，合并后必须校验 SHA-256
二维码解码失败常不是算法问题，而是切片/合并过程引入了空字节、截断或偏移。尤其注意：
-
ofstream默认不加std::ios::binary标志 → Windows 下会把\x0A转成\x0D\x0A，破坏原始二进制 - 切片最后一块若不足指定大小，仍要原样写入（不能补零），否则解码器收到多余字节会失败
- 合并完成后立刻计算源文件与合成文件的
SHA256哈希，二者必须完全一致——这是唯一可信的完整性判断依据
可用 OpenSSL 的 C++ 封装或简易 SHA-256 实现（如 sha256.h 单头库），别用 CRC32 —— 它无法检测小范围重复或重排。
跨平台路径拼接要用 std::filesystem::path，别手拼 "./slices/" + name
硬编码 / 或 \ 在 Windows 和 Linux 下都会出问题；用 + 拼接 std::string 易忽略路径分隔符逻辑。C++17 的 std::filesystem::path 是唯一稳妥方案。
- 构造路径用
fs::path dir = "slices"; fs::path p = dir / "slice_0001.bin"; - 检查文件存在用
fs::exists(p)，比std::ifstream(p.string()).is_open()更可靠 - 注意：MSVC 19.20+、GCC 9+、Clang 10+ 才完整支持，老环境需回退到 Boost.Filesystem 或手动处理分隔符
切片和合并逻辑本身不复杂，真正卡住人的永远是边界情况：最后一片读不满、路径斜杠、二进制换行、哈希没校验。把这些点盯死，比堆砌花哨 API 管用得多。
