主线程提前退出是因为未处理joinable的std::thread对象，其析构时强制调用std::terminate()导致崩溃；必须在对象销毁前显式调用join()或detach()。
用 std::thread 并行加密多个文件时，为什么主线程提前退出？
因为 std::thread 对象析构时若仍处于 joinable() 状态，会直接调用 std::terminate()。这不是“卡住”，而是程序崩溃——常见于忘记 join() 或 detach()。
- 每个
std::thread实例必须显式处理：要么在作用域结束前调用t.join()，要么确认t.detach()安全（比如线程完全自治、不访问局部变量） - 推荐用
std::vector<:thread></:thread>存储所有线程，最后统一join()；避免在循环里直接声明并丢弃线程对象 - 别在线程函数里直接操作
std::cout——多线程写同一输出流可能乱序或阻塞，加std::mutex保护，或改用日志文件
AES 加密选 OpenSSL 还是 libsodium？
libsodium 更适合工具类场景：API 简洁、默认安全（如自动选 AEAD 模式）、无内存管理陷阱；OpenSSL 灵活但容易配错（比如误用 ECB、忽略 IV 随机性、漏清零密钥缓冲区）。
- 用
sodium_init()初始化一次即可，不用管底层引擎 - 加密单个文件建议用
crypto_secretstream_xchacha20poly1305：流式接口、自带认证、IV 自动生成并前置写入文件头 - 密钥不能硬编码，应从用户口令派生：
crypto_pwhash()+SCRYPT_OPSLIMIT_INTERACTIVE参数，盐值随机生成并存进加密后文件头 - 务必在使用后用
sodium_memzero()清零密钥、口令、临时缓冲区——memset()可能被编译器优化掉
读写大文件时线程卡住，是不是锁冲突？
不是锁的问题，是 I/O 瓶颈被放大了。多线程同时读写同一块磁盘（尤其机械硬盘），随机寻道会让吞吐暴跌；SSD 好些，但并发过高仍可能触发队列拥塞。
- 限制并发线程数：用
std::thread::hardware_concurrency()作上限参考，但实际设为min(4, N)更稳（N 是待处理文件数） - 每个线程独占一个输入/输出文件流：
std::ifstream和std::ofstream不共享状态，无需额外锁 - 避免小块读写：设置缓冲区大小（如 64KB），用
read(buf, size)批量读取，减少系统调用次数 - 如果必须加密单个超大文件（>1GB），别拆成多线程分段——AES-CBC 分段需传递上一段的密文块作 IV，逻辑复杂且易出错；老老实实用单线程流式加密
加密后文件打不开，错误信息是 bad decrypt 或校验失败
大概率是 IV、盐值、认证标签没和密文一起持久化，或读取时顺序/长度错位。流式加密格式必须自描述。
- 推荐固定头部结构：4 字节 magic（如 "CENC"）+ 1 字节版本 + 16 字节 salt + 24 字节 header（
crypto_secretstream_xchacha20poly1305_init_push输出）+ 密文 + 16 字节 tag - 解密时先验证 magic 和版本，再读 salt 重派生密钥，用 header 初始化解密流，最后逐块解密并校验 tag
- 不要把加密后文件后缀简单改成
.enc就完事——得确保解密程序能从文件头准确还原全部元数据 - 测试时用已知明文（如全零文件）和固定口令，比对加密前后哈希，快速定位是算法问题还是序列化问题
std::thread 要花更多时间验证。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
