std::thread 跑图片缩放任务时主线程提前退出常见现象是程序一闪而过输出目录空空如也——std::thread对象离开作用域时若未join()或detach()会触发std::terminate。这不是“没跑完”而是直接崩溃了。实操建议用std::vector:thread/:thread管理所有工作线程构造完再统一join()避免在循环体内直接创建并丢弃std::thread对象更稳妥的做法是把线程对象 push_back 到 vector最后遍历 join如果某张图处理失败比如 OpenCV 读取返回空cv::Mat别让异常穿透线程函数——加try/catch(...)吞掉否则整个进程挂掉OpenCV imread resize 多线程并发读写冲突cv::imread和cv::imwrite在多线程下不是完全线程安全的尤其 Windows 上用默认后端MS-Photo时频繁并发调用可能引发断言失败或图像损坏。实操建议显式指定解码后端用cv::IMREAD_UNCHANGED | cv::IMREAD_ANYDEPTH等标志避开系统默认解码器对cv::imread加细粒度互斥锁不现实更推荐每个线程独占一个cv::Mat实例且避免跨线程传递原始指针缩放前检查mat.empty() false跳过无效输入防止cv::resize对空矩阵崩溃线程数设多少才不拖慢批量缩放CPU 密集型任务如双线性插值缩放线程数 ≠ 核心数就一定最优。I/O 等待、内存带宽、OpenCV 内部并行如启用 TBB都会干扰实际吞吐。实操建议从std::thread::hardware_concurrency()开始试但通常设为min(8, hardware_concurrency())更稳——太多线程反而因上下文切换和缓存抖动降低效率用cv::setNumThreads(0)关闭 OpenCV 自身的多线程它和你的线程池叠加容易过载对小图 4 后收益急剧下降大图10MP可适当提高但务必压测验证路径中文乱码导致 imread 返回空 MatWindows 下用cv::imread(D:\测试\a.jpg)直接失败mat.empty()为 true——OpenCV 的 C 接口不支持 UTF-8 路径std::string构造的路径在中文系统下被当作了 GBK 编码解析。实操建议Windows 上改用cv::imread(cv::utils::fs::canonical(path).u8string())需 OpenCV 4.5.2更通用方案先用std::filesystem::u8path()转成 UTF-8 字符串再转std::string传入注意 MSVC 19.28 才完整支持u8pathLinux/macOS 一般无此问题但路径含空格仍需确保传入的是原生字符串不要被 shell 层截断实际缩放逻辑本身不复杂真正卡住人的永远是线程生命周期管理、OpenCV 底层行为边界、以及跨平台路径编码这些“非算法”细节。别在cv::resize参数上花太多时间调优先确保每张图都稳稳地读进来、缩放完、写出去。