std::thread对象析构时若仍joinable会直接调用std::terminate()导致程序静默终止；必须显式join或detach，推荐用vector存储后统一join，或RAII封装自动管理。
std::thread 启动解密任务时，为什么主线程提前退出？
因为 std::thread 对象析构时若仍处于可连接（joinable）状态，会直接调用 std::terminate()。这不是崩溃日志里写“segmentation fault”那种错误，而是静默终止——你甚至可能只看到程序输出几行就结束了。
必须显式处理每个线程的生命周期：
- 在循环创建线程后，把
std::thread对象存入std::vector<:thread></:thread>，避免临时对象被销毁 - 所有任务启动完毕后，遍历 vector 调用
.join()—— 不要用.detach()，脱离后无法同步完成状态，文件写入可能冲突或不完整 - 如果某线程抛异常导致未 join，可用 RAII 封装：写个简单的
scoped_thread类，在构造时接管 thread，析构时自动 join（前提是没被 move 走）
多个线程同时写同一个输出目录，怎么避免文件名冲突？
不要让线程自己拼接输出路径，比如都用 input_path + ".dec"；一旦两个线程处理同名但不同路径的文件（如 ./a/secret.bin 和 ./b/secret.bin），就会覆盖。
安全做法是保留原始路径结构，或生成唯一标识：
立即学习“C++免费学习笔记（深入）”；
- 输出路径基于输入路径做相对映射：
std::filesystem::path out_path = output_root / (in_path.lexically_relative(input_root).replace_extension(".dec")) - 或用哈希（如 xxhash）对完整输入路径做 short hash，拼成
out/xxx_dec_9f3a2b.dec，比时间戳或 pid 更可靠 - 创建输出文件前，先调用
std::filesystem::create_directories(out_path.parent_path())，别假设目录一定存在
用 OpenSSL 的 EVP API 多线程解密时，是否要加锁？
只要每个线程使用独立的 EVP_CIPHER_CTX* 实例，且不共享密钥材料（const unsigned char* 可以共享），就完全不需要锁。OpenSSL 1.1.1+ 的 EVP 接口本身是线程安全的。
但要注意几个硬坑：
-
EVP_DecryptInit_ex()必须传非 NULL 的impl参数（通常填nullptr），否则某些平台（尤其是 Windows + static lib）会 crash - AES-GCM 模式下，每个线程必须用唯一 IV（nonce），不能复用；建议从文件头读取 12 字节 IV，或用
RAND_bytes()生成——千万别用time(nullptr) - 解密失败时，
EVP_DecryptFinal_ex()返回 0，此时要检查ERR_get_error()，常见原因是 IV 长度错、密钥长度不匹配、或认证失败（GCM tag 校验失败）
解密任务量小但线程数多，为什么反而更慢？
线程创建/销毁开销远大于单个小文件（比如几十 KB）的解密耗时。实测在 4 核机器上，用 16 个线程解 20 个 50KB 文件，比 4 线程慢 3 倍以上。
合理控制并发度：
- 用
std::thread::hardware_concurrency()作上限，但实际设为min(4, hardware_concurrency())更稳 - 对大文件（>1MB）可单独启用线程内分块流水解密（decrypt → write → next chunk），但这需要自己管理 buffer 和 offset，不是简单扔给 thread
- 更推荐用线程池 + 任务队列（如
concurrent_queue<std::string>），预先把所有文件路径 push 进去，N 个固定线程持续取任务，避免反复构造 thread 对象
真正卡住性能的往往不是算法，而是磁盘随机读（尤其机械盘）和小文件频繁 open/write。如果输入文件都在同一目录且顺序排列，批量读取+内存解密+合并写入，有时比多线程还快。
