简介：OpenCASCADE 7.5.0 预编译库是面向三维 CAD/CAM/CAE 与工业仿真开发者的 Windows+Qt 平台资源，适用于工业机器人仿真、三维模型显示、三角剖分、三维实体布尔运算等典型场景。该包已提前编译好动态库与头文件，省去从源码构建 OCCT 的漫长过程，同时涵盖 QT5.9.1/mingw530_32 与 QT5.14.2/mingw730_64 两套版本，按 win32 或 win64 目录选择即可直接集成到工程中使用。压缩包共 2000 个文件，整体约 70.02MB；其中 1766 个 hxx 头文件与 128 个 lxx 模板实现声明了类与接口，57 个 dll 为程序运行所需的动态链接库，另有 25 个 gxx、22 个 h、1 个 txt 与 1 个 exe，基本覆盖了几何内核、数据交换、可视化等模块的编译产物，目录划分明确、便于检索。目前已有 74 人浏览学习这份资源。作者注明内容源自网络分享，若积分不足可私信获取；无论初学者还是专业开发，都能借此快速搭建 OCCT 环境，推进三维模型显示与仿真项目。
1. OpenCASCADE 7.5.0 预编译库：跳过源码编译，直接喂给 Qt 和 MinGW
OpenCASCADE 7.5.0 预编译库是我在 Windows 上做几何内核试验时最常用到的资源：它把官方那套“源码下来还得用 CMake 配依赖”的流程直接压成一包二进制，我只需要按自己的编译器选 win32 或 win64 目录，配合 Qt 的 MinGW 工具链就能跑起来。对个人学习来说，这个组合比从源码编译节省几个小时，而且踩坑范围从“编译失败”收窄到“链接路径不对”。这篇文章就是按我实际拆包、配置、验证的顺序来的，适合想用 Qt + MinGW 写 CAD/CAM 小工具，又不想在 OCCT 源码构建上耗太久的人。
2. 为什么要先认准 7.5.0 的二进制与 MinGW 的匹配：版本和编译器差一处就翻车
拿到预编译库的第一件事不是急着写代码，而是确认三件事：OCCT 版本、Qt 版本、编译器是 MinGW 还是 MSVC。这三者一旦错配，后面所有报错都会变得很抽象。
2.1 预编译库的目录结构，先弄清楚哪部分能直接用
我习惯把 OpenCASCADE 7.5.0 解压到一个不带空格的路径下，比如D:/OpenCASCADE/7.5.0。大多数 Windows 预编译包长这样：
| 目录/文件 | 里面是什么 | 对这个场景的用处 |
|---|---|---|
inc | 所有.hxx头文件 | 编译时INCLUDEPATH指向它 |
win64/lib | MinGW 64 位的导入库.a | 链接时LIBS指向它 |
win32/lib | MinGW 32 位的导入库.a | 做 32 位套件时用 |
bin | 运行时 DLL，比如TKernel.dll、TKMath.dll | 程序运行时要能找到它们 |
resources | OCC 默认着色器、字体、单位字典 | 用到可视化模块时再引入 |
src | 部分源码/示例补全 | 翻函数定义时很有用 |
这里最容易被忽略的是bin目录。很多新手把inc和lib配好了，一运行就报“找不到 TKernel.dll”。原因就是 DLL 搜索路径里没有bin。个人学习阶段，我一般不会把 OCCT 的 DLL 拷到 exe 目录，而是直接把bin加进 PATH，因为要同时试验 32 位和 64 位时，换套件更方便。
选 7.5.0 而不是更新的 7.6/7.7，不是图版本旧，而是因为 7.5.0 对 Qt 5.15 和 MinGW 8.1 的兼容资料最多，遇到问题网上一搜就能对上号。新版本引入的 OpenGL 渲染改动比较大，对只想验证建模算法的人来说收益不大，反而可能因为显卡驱动或 Qt 版本不匹配带来额外噪音。
2.2 MinGW 与 MSVC 的区别：为什么预编译库必须和 Qt 一起选对
MSVC 和 MinGW 是 Windows 上两种完全不同的 C++ ABI。MSVC 用的是微软的导入库.lib和运行时VCRUNTIME，MinGW 用的是 GNU 的导入库.a和运行时libstdc++-6.dll。两者编译出的 C++ 符号修饰规则不同，目标文件里的__imp_解析方式也不同，所以没法直接混用。
如果 OCCT 预编译包是做给 MSVC 的，你拿 MinGW 去链接，通常会出现：
undefined reference to __imp__ZN...因为 MinGW 编译器看到的符号和 MSVC 生成的导入库符号对不上。反过来，把 MinGW 的.a丢给 MSVC 也一样没法用。所以在下载预编译库时，一定要认准“MinGW 版”而不是“vc14/vc15 版”。这个选择直接决定后面 Qt 是装 msvc2019_64 还是 mingw81_64。
Qt 官方安装包里会同时提供MSVC 2019 64-bit和MinGW 8.1.0 64-bit两套组件。给 OCCT 用必须选后者，或者更准确地说，选和你 OCCT 包对应的那一个 MinGW 大版本。原因在于 MinGW 8.1 和更老的 MinGW 7.3 虽然都是 GCC，但 C++ 标准库和异常处理实现有差异，混用同样会在运行期出怪问题。
至于 32 位还是 64 位，印象里很多人以为 64 位 Windows 就只能用 64 位库。实际上 Qt Creator 完全可以装一套mingw81_32的 Kit，跑 32 位版本。什么时候会用到？比如以后要接入某个只提供 32 位 SDK 的工业相机或运动控制卡，你就得被迫切到 32 位。个人学习建议优先 64 位，因为 OCCT 处理大模型时内存占用很容易超过 2 GB，64 位地址空间更从容。
3. 把库配置进 Qt Creator：从环境变量到工程文件
这一章是动手的核心。我会先做环境变量，再分别给出 qmake 和 CMake 两种接入方式。因为预编译库来源不同，有的带 CMake 配置文件，有的不带，所以两条路都得会。
3.1 目录与环境变量准备
解压后第一件事是加环境变量。我常用 PowerShell 命令行临时设置来做验证：
$env:OCC_ROOT = "D:/OpenCASCADE/7.5.0" $env:PATH = "$env:OCC_ROOT/win64/bin;" + $env:PATHOCC_ROOT是指向 OCCT 根目录的变量，后面 .pro 和 CMake 都可以引用它。PATH里的win64/bin是运行时 DLL 的位置。注意这里是win64/bin，不是bin，因为同一个包放了两套架构的 DLL。如果你同时把win32/bin也塞进 PATH，运行时会按 PATH 先后顺序随机加载其中一套，程序要么启动即崩，要么明明链接的是 64 位库却报“0xc000007b”。
提示：改完系统环境变量后，Qt Creator 必须彻底重启一次，不然它还留着旧的 PATH，运行阶段照样找不到 DLL。
3.2 用 qmake 接入：.pro 文件里的具体写法
qmake 是 Qt Widgets 项目最常见的构建方式，配置起来最直接。下面是一个真实可用的.pro片段：
QT += core gui greaterThan(QT_MAJOR_VERSION, 4): QT += widgets TEMPLATE = app CONFIG += console c++14 SOURCES += main.cpp OCC_ROOT = D:/OpenCASCADE/7.5.0 INCLUDEPATH += $$OCC_ROOT/inc # 注意：MinGW 链接顺序很敏感，这里用 group 包起来 LIBS += -L$$OCC_ROOT/win64/lib LIBS += -Wl,--start-group \ -lTKernel \ -lTKMath \ -lTKBRep \ -lTKTopAlgo \ -lTKPrim \ -Wl,--end-groupCONFIG += console是给验证程序用的，让qDebug()能直接输出到控制台，不用被 Qt 的 GUI 窗口盖住。c++14是兼容 OCCT 7.5.0 的最低标准。
-Wl,--start-group和-Wl,--end-group是 GNU 链接器参数，解决 MinGW 下库之间循环依赖的问题。OpenCASCADE 的模块分层并不是严格的单向依赖：TKPrim会调用TKBRep，TKBRep又可能依赖TKMath。普通-l顺序错了就报 undefined reference，加上 group 后链接器会反复扫描指定库，直到符号全部解析。这是个人学习和实战里最值得记住的一个参数。
需要打开 STEP 文件时，再往 LIBS 里加-lTKSTEP -lTKXSBase。验证阶段先不加，能少解释很多错误。
3.3 用 CMake 接入：Toolchain 与 CMAKE_PREFIX_PATH
现在不少新项目直接从 CMake 起步。OCCT 官方安装包带OpenCASCADEConfig.cmake，理论上可以find_package(OpenCASCADE)。但社区里流出的精简预编译包经常不带这个配置文件。我一般会先试一下，找不到就走手动路径。
手动配置的 CMakeLists核心部分：
cmake_minimum_required(VERSION 3.16) project(occ_demo LANGUAGES CXX) set(CMAKE_CXX_STANDARD 14) # 让 CMake 找到 Qt 的 MinGW 包 set(CMAKE_PREFIX_PATH "D:/Qt/5.15.2/mingw81_64") find_package(Qt5 REQUIRED COMPONENTS Core Gui Widgets) # 手动指认 OCCT 路径 set(OCC_ROOT "D:/OpenCASCADE/7.5.0") include_directories(${OCC_ROOT}/inc) add_executable(occ_demo main.cpp) target_link_libraries(occ_demo PRIVATE Qt5::Widgets ${OCC_ROOT}/win64/lib/libTKernel.a ${OCC_ROOT}/win64/lib/libTKMath.a ${OCC_ROOT}/win64/lib/libTKBRep.a ${OCC_ROOT}/win64/lib/libTKTopAlgo.a ${OCC_ROOT}/win64/lib/libTKPrim.a )这里直接写libTKernel.a而不是-lTKernel，是为了让 CMake 不依赖额外的LINK_DIRECTORIES搜索路径。MinGW 下 OCCT 的导入库后缀是.a，与 MSVC 的.lib不同。如果 CMake 报找不到Qt5::Widgets，优先检查CMAKE_PREFIX_PATH是否指向了你当前 Kit 对应的那个 Qt 目录，而不是msvc2019_64。
3.4 Kit 切换：一次配好 32/64 两套构建
我强烈建议在 Qt Creator 里把 32 位和 64 位当成两个独立 Kit 配置，而不是反复改系统 PATH。具体做法是：在“工具 → 选项 → Kits”里新增两个手工套件。
| 套件名 | 编译器 | Qt 版本 | OCCT 库目录 |
|---|---|---|---|
| OCC 64-bit | MinGW 8.1.0 64-bit | Qt 5.15.2 MinGW 64-bit | D:/OpenCASCADE/7.5.0/win64/lib |
| OCC 32-bit | MinGW 8.1.0 32-bit | Qt 5.15.2 MinGW 32-bit | D:/OpenCASCADE/7.5.0/win32/lib |
配置完成后，切换套件只需要在 Qt Creator 左下角点一下，构建目录会各自独立，互不污染。需要注意：32 位 Qt 和 64 位 Qt 不能共用同一个构建目录，否则 CMake 缓存里残留的路径会把两个架构的库混在一起。
4. 写一个装着 OCCT 的 Qt 程序：从盒体生成到 BRep 落盘
这一步的目标不是写复杂的 CAD 界面，而是用最小代码确认 OCCT 7.5.0 真的能在当前 Kit 下链接、加载、运行。我的做法是生成一个长方体外壳，用 Qt 的qDebug()打印结果，再导出成 BRep 文件。
4.1 最小可运行的 main.cpp
#include <QApplication> #include <QDebug> #include <gp_Pnt.hxx> #include <BRepPrimAPI_MakeBox.hxx> #include <TopoDS_Shape.hxx> #include <BRepTools.hxx> int main(int argc, char *argv[]) { QApplication app(argc, argv); // 在原点 (0,0,0) 生成长 100、宽 200、高 300 的长方体 gp_Pnt origin(0.0, 0.0, 0.0); BRepPrimAPI_MakeBox makeBox(origin, 100.0, 200.0, 300.0); if (!makeBox.IsDone()) { qCritical() << "box build failed"; return 1; } TopoDS_Shape shape = makeBox.Shape(); qDebug() << "shape null?" << shape.IsNull(); // 写入 BRep 文件，文件保存在当前工作目录 BRepTools::Write(shape, "box.brep"); qDebug() << "BRep file written"; return 0; }BRepPrimAPI_MakeBox是 OCCT 里最基本的造型 API。构造参数除了原点，还可以直接接收长宽高三个Standard_Real，单位默认是毫米。这个程序跑通，说明TKPrim、TKBRep、TKMath、TKernel四条链接链路全部正常。
makeBox.Shape()返回的是TopoDS_Shape，它只是几何对象的拓扑容器，真正数据还在底层 TShape 里。BRepTools::Write会把它序列化成 OCCT 自己的.brep文件。个人学习时，这个文件可以直接拿给官方Draw查看器打开，也可以作为后续网格剖分的输入。
4.2 用包围盒验证几何结果
光写入文件还不够，我在实际调试时还会加一段包围盒计算，用来确认模型尺寸没有因为单位或参数写错而变成 0：
#include <Bnd_Box.hxx> #include <BRepBndLib.hxx> // ... 接上面的 shape Bnd_Box bbox; BRepBndLib::Add(shape, bbox); gp_Pnt minP = bbox.CornerMin(); gp_Pnt maxP = bbox.CornerMax(); qDebug() << "min:" << minP.X() << minP.Y() << minP.Z(); qDebug() << "max:" << maxP.X() << maxP.Y() << maxP.Z();BRepBndLib::Add会遍历几何形状，把包围盒范围算出来。如果输出是min:0 0 0 max:100 200 300，说明拓扑数据正确。这个小验证的价值在于，它把“链接成功”和“算法数据正确”分开。很多预编译库链接能过，但运行期因为 DLL 版本不对，数据全是 0。问题一旦出现在这一步，后面画图全是废的。
4.3 扩展到 STEP 文件读取
盒体验证完，下一步最常见的需求是读取 STEP 文件。OCCT 7.5.0 里用STEPControl_Reader处理：
#include <STEPControl_Reader.hxx> #include <IFSelect_ReturnStatus.hxx> STEPControl_Reader reader; IFSelect_ReturnStatus status = reader.ReadFile("part.step"); if (status != IFSelect_RetDone) { qWarning() << "read step failed, status:" << status; return 1; } reader.TransferRoots(); TopoDS_Shape stepShape = reader.OneShape();这里需要额外链接TKSTEP和TKXSBase。记住在.pro的LIBS里加：
LIBS += -lTKSTEP -lTKXSBaseTransferRoots()返回的是成功传输的实体数量，不是错误码。我见过有人把它的返回值当成 bool 用，结果明明是 1 个实体，返回 1，被误判为错误。更稳妥的写法是调用后直接取reader.NbShapes()，大于 0 才继续。
5. 常见问题与避坑排查：五个开关决定能不能跑起来
这一章是从我反复翻车记录里挑出来的高发问题。每一条都按“现象 → 原因 → 解决”整理，你可以直接对号入座。
5.1 Qt Creator 报:-1: error: dependent '.../msvc2019_64/include/QtWidgets' does not exist
现象：新建项目后一编译，Qt Creator 抛错，后面跟着一长串qt/5.15.2/msvc2019_64/include/qtwidgets之类的路径，提示不存在。明明我用的就是 Qt，为什么找不到？
原因：项目文件.pro没问题，问题出在 Kit。Qt Creator 的构建套件里选择的 Qt 版本是某个 MSVC 系的 Qt，比如Qt 5.15.2 MSVC2019 64bit。OCCT 预编译库是 MinGW 的，编译器也切成了 MinGW，但 Qt 版本没跟着切，于是依赖路径还指向msvc2019_64。
解决：打开“工具 → 选项 → Kits → Qt Versions”，确认当前套件绑定的是mingw81_64或mingw81_32。改完后再删掉项目根目录的build文件夹，重新执行 qmake。如果还报同样错误，说明.pro.user文件残留了旧的 Qt 路径，直接把.pro.user删了让 Qt Creator 重新生成即可。
5.2 程序启动报“应用程序无法正常启动 0xc000007b”
现象：编译顺利通过，一运行就弹0xc000007b，看起来像系统错误，但代码和项目配置都没问题。
原因：这个错误绝大多数情况是 32/64 位架构混用。我遇到最典型的是：MinGW 64 位编译器链接了win32/lib里的 OCCT 导入库，或者 PATH 里同时存在win32/bin和win64/bin，运行时优先加载了 32 位的TKernel.dll。
解决：先确认 Qt Creator 左下角套件是 64 位还是 32 位，然后检查 CMake/.pro里指向的 OCCT 目录必须和套件一致。再用where TKernel.dll查看当前环境实际会加载哪个 DLL。如果 PATH 里混了两套，就把不需要的那一条从系统 PATH 里删掉，重启 Qt Creator 再跑。个人开发机上尽量不要同时保留两个版本路径。
5.3 链接报undefined reference to __imp_系列符号
现象：MinGW 编译器在链接阶段报一堆undefined reference to __imp__ZN...，符号看着头都大。但头文件和库目录都配了，include 也能找到。
原因：多半是 OCCT 库文件用错了。你链接的那个.lib或.a是 MSVC 编译器导出的导入库，而当前工具链是 MinGW。MSVC 和 MinGW 的 ABI 不兼容，符号修饰规则不同，所以即使函数名一样，也解析不了。
解决：回到预编译库目录，重新确认win64/lib里面的文件后缀。MinGW 用的是libTKernel.a，而 MSVC 用的是TKernel.lib。如果下载包本身是 MSVC 版，那就得换包，或者放弃 MinGW 改用 MSVC 套件。这个坑没有任何编译参数能绕过去。
5.4 缺少libstdc++-6.dll或libgomp-1.dll
现象：程序在 IDE 里跑正常，直接双击 exe 却提示缺少 DLL，或者换了一台没装 Qt 的机器立刻崩溃。
原因：OCCT 的 MinGW 预编译库是用特定版本的 GCC 编译的，运行期依赖 GCC 的运行时 DLL，比如libstdc++-6.dll、libgcc_s_seh-1.dll、libwinpthread-1.dll。这些文件在 Qt 自带的 MinGW 工具链目录里，不在 OCCT 包里，也不在 Windows 系统目录里。
解决：把D:/Qt/Tools/mingw810_64/bin加入系统 PATH。注意不是 Qt 的5.15.2/mingw81_64/bin，而是 Qt 安装目录下Tools里的编译器运行时。调试的时候加到 PATH 即可，正式发版再考虑把这些 DLL 复制到 exe 目录或做静默安装打包。
5.5 32 位程序在 64 位系统上跑出“不是有效 Win32 应用程序”
现象：套件切到 32 位后，编译和链接都成功，运行时报“不是有效的 Win32 应用程序”或直接闪退，而同一个代码用 64 位套件没问题。
原因：这是典型的 CMake 缓存问题。之前你用 64 位套件构建了一个build-win64目录，后来直接在同一个目录切到 32 位套件。CMake 没有把所有目标文件清掉，链接器把 32 位和 64 位的.obj混在一起，生成了个不伦不类的 PE 文件。
解决：切架构时不要复用构建目录。我的习惯是构建目录直接带上架构名：
mkdir build-win64 mkdir build-win32然后分别配置、构建、运行。Qt Creator 的 Shadow Build 功能也支持为每个 Kit 单独维护一套构建目录，只要在“Projects → Build Settings”里把目录名称改成build-win64、build-win32，就能彻底避开这个坑。
6. 用 objdump 和版本宏做套件诊断：五分钟确认二进制到底对不对
最后一个技巧是我自己的强制校验流程。每次换 OCCT 预编译库版本，或者换一台电脑重装 Qt，我都不会急着写业务代码，而是花五分钟跑完三步检查。
第一步，用 objdump 看 DLL 架构。Qt 的 MinGW 工具链自带 objdump，不需要额外装工具：
D:/Qt/Tools/mingw810_64/bin/objdump.exe -f D:/OpenCASCADE/7.5.0/win64/bin/TKernel.dll看输出里的file format一行。pei-x86-64是 64 位，pei-i386是 32 位。拿它去对应你的 Qt 套件，架构不匹配就不用继续了。
第二步，在程序里打印 OCCT 的版本宏。在main.cpp里加一行：
#include <Standard_Version.hxx> qDebug() << "OCCT" << OCC_VERSION_STRING;OCC_VERSION_STRING是Standard_Version.hxx里预编译期定义的字符串宏。如果能看到7.5.0，说明你 include 的头文件和链接的库确实是同一个版本，而没有发生“头文件是 7.5.0、库却是 7.6.0”的串包问题。
第三步，也是最实在的一步，就是把第四章那个盒体程序原样跑一遍。不要改参数，不要加界面，只要包围盒输出能对上一次，这套预编译库在当前 Qt 和 MinGW 工具链组合下就算真正站稳了。之后再引入 STEP、网格、渲染模块，心里才有底。
从那以后，我每次换 Kit、换机器、换预编译库包，都会强制走一遍这套流程：objdump 看架构，版本宏看头文件和库的匹配，盒体程序看真实运算结果。一套流程五分钟不到，但能省下后面一整个晚上的排错时间。希望帮到你。
本文还有配套的精品资源，点击获取
