Visual Studio 默认不启用 OpenMP，需手动开启 /openmp 编译选项，否则 #pragma omp 指令被忽略；CMake 项目须用 find_package(OpenMP) 和 target_link_libraries 启用。
Visual Studio 默认不启用 OpenMP，必须手动开启编译器支持，否则所有 #pragma omp 指令都会被忽略——这是 90% 的人第一次写并行循环却没效果的根本原因。
VS 项目属性中必须启用 /openmp 编译选项
在项目右键 → “属性” → “C/C++” → “语言” 页面，找到“OpenMP 支持”选项，设为“是（/openmp）”。注意：该设置按配置生效（Debug/Release）和平台（x64/x86）独立，务必确认你当前选中的配置和平台已正确设置。若使用 x86 平台，omp_get_max_threads() 可能返回异常小的值（如 2），而 x64 下通常匹配物理核心数；建议统一用 x64 开发和测试。
常见错误现象：
- 写了
#pragma omp parallel for，但任务始终只跑在一个核心上，omp_get_num_threads()返回 1 - 编译无报错，但运行时 CPU 占用率不上升，性能毫无变化
- 链接时报错 LNK2019：未解析的外部符号
omp_get_thread_num—— 这说明运行时库没链上，但 /openmp 开启后 MSVC 会自动链接libomp.lib，因此该错误往往意味着 /openmp 根本没开成功
CMake 项目不能靠属性页，得改 CMakeLists.txt
如果你用的是 Visual Studio 的 CMake 项目（即根目录有 CMakeLists.txt），项目右键没有“属性页”，此时必须在 CMakeLists.txt 中显式启用 OpenMP。VS 的 CMake 集成不会自动读取 GUI 属性设置。
立即学习“C++免费学习笔记（深入）”；
正确做法（CMake 3.9+）：
- 在
CMakeLists.txt开头附近添加：find_package(OpenMP REQUIRED COMPONENTS CXX) - 在
add_executable(...)或add_library(...)之后，加上：target_link_libraries(your_target_name OpenMP::OpenMP_CXX)
不要手动写 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /openmp") —— 这种写法绕过 CMake 的依赖管理，容易导致 Debug/Release 链接不一致，且在跨平台构建时失效。
并行 for 循环前加 #pragma omp parallel for 不等于自动加速
OpenMP 不会 magically 加速任意循环。它只对计算密集、迭代间无强依赖、且总迭代次数足够大的循环有效。一个典型反例：for (int i = 0; i 并行化后反而更慢，因为线程创建/同步开销远超计算本身。
实用建议：
- 确保循环体至少包含数百次浮点运算或内存访问，否则别并行
- 避免在循环内调用不可重入函数（如
rand()）、或直接读写同一全局变量——这会导致数据竞争；改用reduction（如reduction(+:sum)）或critical区域保护 - 用
omp_get_num_procs()和omp_get_num_threads()在运行时确认实际使用的线程数，别假设它等于核心数；Windows 调度策略可能限制并发度
别忽略运行时线程数控制与调度策略
即使开了 /openmp，#pragma omp parallel for 默认使用 static 调度，且线程数由环境变量 OMP_NUM_THREADS 或 omp_set_num_threads() 控制。VS 启动的调试进程默认不继承系统环境变量，所以你在终端里设了 set OMP_NUM_THREADS=8，VS 里跑还是按默认逻辑（通常是核心数）。
可靠做法：
- 在
main()开头尽早调用：omp_set_num_threads(8);（数值按需调整） - 对负载不均的循环（如每次迭代耗时不等），显式加调度子句：
#pragma omp parallel for schedule(dynamic, 32) - 禁用嵌套并行（默认关闭）：除非你明确需要，否则别碰
omp_set_nested(1)，它会让线程数爆炸式增长，反而拖慢整体
最容易被忽略的一点：OpenMP 并行区内部无法捕获 C++ 异常。如果某次迭代抛出异常，整个程序会 abort。真要处理异常，得在并行区内用 try/catch 包裹，且不能让异常逃出并行区边界。
