做工业软件或者三维应用开发的朋友，大概率都经历过这么一个阶段：界面搭得有模有样，菜单、工具栏、属性面板一应俱全，结果一到“真正生成一个实体”这一步就卡住了，最后发现绕不过去的东西叫几何内核。OpenCascade（圈内一般简称 OCC，正式名称是 Open CASCADE Technology）就是这块领域里少数开源、且允许商用的一套完整内核。我这几年做设备建模、模型轻量化、在线报价这类活，前后被它折腾过好几轮，也翻烂了能找到的所有 OpenCascade 中文教程和零散的博客笔记。

这篇东西不打算给你背文档。我想做的是把“一个中文教程应该讲清楚但经常讲不清楚的东西”串起来：OCC 到底处在技术栈的哪一层、环境怎么搭才不白折腾三天、几个核心概念为什么这么设计、以及从一个空白工程到导出一个能用的 STEP 文件，中间每一步的真实操作和真实坑点。适合已经会 C++、想用 OCC 做实际功能的人，也适合刚接手一个用了 OCC 的老项目、需要快速摸清底细的人。零基础也能看，但我不会从“什么是类”开始讲。

1. 先搞清楚 OCC 到底是个什么层级的工具

1.1 它提供的是一套几何能力，不是一个 CAD 软件

很多人第一次接触 OCC，是听说“这是个开源的 CAD 内核”，然后下意识地以为装完就有个能画图的软件。不是的。OCC 给的是一堆类和算法：边界表示（BRep）的拓扑结构、NURBS 曲线曲面、布尔运算、倒角抽壳、网格离散、STEP/IGES/STL 读写、以及一层包在 OpenGL 外面的可视化框架。它不提供用户界面、不提供参数化特征树、不提供草图约束求解、不提供工程图和刀路。

我一般这么跟人解释这个分工：OCC 相当于一台完整的发动机总成，曲轴、缸体、配气机构全给你了，但车壳、方向盘、仪表盘、变速箱匹配，得你自己造。所以正确的心智模型是“我在做自己的 CAD 类应用，几何这部分外包给 OCC”，而不是“我在用一个现成的 CAD 软件”。

这个定位直接决定了学习重点。你要花力气的地方不是界面，是拓扑结构怎么组织、布尔运算为什么会失败、容差怎么控制、大模型怎么加速。这三件事搞不定，界面做得再漂亮都是空壳。

1.2 中文资料稀缺是真实痛点，但稀缺里藏着机会

官方文档是用注释工具自动生成的类说明，每个类都有，但只有“这个函数干什么”，没有“什么时候该用哪个类、几个类怎么配合”。比如BRepOffsetAPI_MakeThickSolid，文档会告诉你它的参数是什么意思，但不会告诉你抽壳失败的九成原因是原模型曲率半径小于壁厚，也不会告诉你失败之后该怎么降级处理。

网上能找到的中文材料大致分三类：一是十几年前的翻译版笔记，代码停留在 6.x 时代，Handle_Geom_Curve这种老写法在 7.x 之后已经不推荐；二是零散的博客，某篇文章解决了一个具体问题，但没有上下文，你照着抄完还是不知道整体怎么串；三是把官方示例翻译一遍的“教程”，跑得通，但学完不会用自己的模型。

所以一份有价值的中文教程，核心不是把英文翻成中文，而是做三件事：标出版本差异（哪些 API 在 7.x 之后改了写法）、按使用场景组织类（建一个实体要用哪几个类、按什么顺序调）、把踩坑经验写进去（什么情况下会失败、失败了怎么办）。这三点才是英文文档里最难直接拿到的部分。

1.3 学到什么程度算够用

我按目标把学习深度分成三档，你可以对号入座。

第一档是调包档：能加载 STEP 文件、遍历里面的实体、读取基本信息、做个简单的缩放或位置调整、再导出去。这一档大概一两周就能拿下，核心是STEPControl_Reader、TopExp_Explorer、BRepBuilderAPI_Transform这几个类。

第二档是构造档：能用基本体、拉伸、旋转、扫掠造出想要的形状，能做布尔、倒角、抽壳，能检查模型有效性，能把体积、面积、包围盒算出来。这一档要一个月左右，难点全在布尔运算的稳定性上。

第三档是算法档：能处理容差传播、能自己做法向和曲率分析、能针对失败案例设计降级策略、能做批量模型的自动化处理。这一档是长期活，靠项目喂。

绝大多数工业软件二次开发、报价系统、模型转换工具，停在第二档就完全够用了。别一上来就钻第三档，容易劝退。

2. 搭环境这一步，九成的坑都埋在开头

2.1 三条路线怎么选，别凭感觉

环境这件事，选错路线浪费的时间比后面写代码多得多。我见过有人为了“纯净”硬啃源码编译，折腾了四天，最后发现只是想要个能读 STEP 的小工具。

我的建议很直接：第一次接触一律走预编译包或者包管理器，先跑通一个最小程序，确认整条链路是活的，再考虑要不要源码编译。先把“它能用”这件事验证了，后面的耐心才撑得住。

2.2 Windows 下源码编译的完整实操

假设你选源码编译，下面是我实测下来最稳的一套流程。

准备阶段：装好带 C++ 桌面开发工作负载的编译环境、CMake（建议 3.20 以上）、以及可选的并行计算库和字体库。源码解压路径绝对不要有中文和空格，这一条能省掉你后面百分之三十的报错。

配置阶段，CMake 关键参数我一般这么给：

cmake -S . -B build -G "Visual Studio 17 2022" -A x64 \ -DCMAKE_INSTALL_PREFIX="D:/occ/install" \ -DBUILD_MODULE_Visualization=ON \ -DBUILD_MODULE_Draw=OFF \ -DBUILD_MODULE_DataExchange=ON \ -DUSE_FREETYPE=ON \ -DUSE_TK=OFF \ -DUSE_TBB=OFF

逐条说下为什么这么选。BUILD_MODULE_Draw=OFF是因为 Draw Test Harness 依赖 Tcl/Tk，纯粹是给内核自己测试用的，做业务根本用不上，关掉能省一大截时间和一堆依赖问题。USE_TBB=OFF是因为并行支持会引入版本匹配问题，你先关掉，等跑起来再开。USE_FREETYPE=ON是为了三维场景里能显示文字标注，做可视化基本都要。

编译阶段：生成解决方案之后，不要在默认的 ALL_BUILD 上直接编，去编INSTALL这个目标，它会把头文件、库文件、资源文件按CMAKE_INSTALL_PREFIX整理到同一个目录，后面配置工程的时候只填一个路径就行。

注意：Debug 和 Release 各编一次。OCC 的库文件带调试后缀（如TKD3Dd.dll），只编一种，另一种模式下链接必然失败，这个报错看起来像“找不到库”，实际是模式不匹配，很容易被误导。

时间预期：四核机器，只开必要模块，单模式大概一个半小时到两个半小时。八核会快一些但不会线性增长，因为最后的链接阶段是串行的。

2.3 Linux 或者包管理器路线

Linux 下思路一样，只是把生成器换掉：

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/opt/occ \ -DBUILD_MODULE_Draw=OFF -DUSE_TK=OFF cmake --build build -j$(nproc) cmake --install build

包管理器路线就一句vcpkg install opencascade:x64-windows，但有个必须记住的规矩：你后面配置工程时用的三元组（triplet），必须和装库时选的一致。如果库是 x64-windows 装的，而你的工程用 x64-windows-static 去链，会得到一堆玄学链接错误。Debug 和 Release 同理，要么两条都装，要么统一只用一种。

2.4 用二十行代码验证整条链路是活的

环境搭完别急着写业务，先跑一个最小验证。这个程序干三件事：造一个长方体、算它的体积、打印出来。如果体积对得上，说明头文件、库、运行时全都通了。

#include <BRepPrimAPI_MakeBox.hxx> #include <GProp_GProps.hxx> #include <BRepGProp.hxx> #include <gp_Pnt.hxx> #include <iostream> int main() { TopoDS_Shape box = BRepPrimAPI_MakeBox(gp_Pnt(0, 0, 0), 100.0, 50.0, 20.0); GProp_GProps props; BRepGProp::VolumeProperties(box, props); std::cout << "volume = " << props.Mass() << std::endl; return 0; }

对应的CMakeLists.txt关键几行：

find_package(OpenCASCADE REQUIRED) target_include_directories(demo PRIVATE ${OpenCASCADE_INCLUDE_DIR}) target_link_libraries(demo PRIVATE ${OpenCASCADE_LIBRARIES})

预期输出是100000。如果出来了但这个数不对，说明单位或者参数理解错了；如果编译期就找不到OpenCASCADE_INCLUDE_DIR，八成是OpenCASCADE_DIR没指到安装目录下那个cmake文件夹。

提示：第一次跑起来之后，把 Debug 和 Release 各跑一遍。这一步花两分钟，能省掉后面几天“为什么我这边好好的，那边一运行就崩”的扯皮。

3. 核心概念拆解：OCC 的世界观

3.1 几何和拓扑是两套东西，别混着用

这是 OCC 里最重要的一条分界线，理解了这条，后面大半的困惑自动消失。

几何（Geom_开头的类）回答的是“这个形状在数学上是什么”：一条Geom_Line是无限长直线，一个Geom_Surface是数学意义上的曲面，它们是参数方程，没有起点终点，也没有边界。

拓扑（TopoDS_开头的类）回答的是“谁和谁连着”：顶点、边、环、面、壳、实体、复合体。边是在几何曲线的基础上加了参数范围，面是在几何曲面的基础上加了裁剪边界。

打个生活化的比方：几何是一张无限大的纸和纸上的所有曲线，拓扑是你用剪刀剪出来的那一块带边界的形状，以及这块形状上的每个角、每条边。你建模的时候，操作对象几乎永远是拓扑，几何只是拓扑背后挂着的数学定义。

遍历一个实体看里面有什么，用TopExp_Explorer：

for (TopExp_Explorer ex(shape, TopAbs_FACE); ex.More(); ex.Next()) { TopoDS_Face face = TopoDS::Face(ex.Current()); // 处理每个面 }

这里的TopAbs_FACE是类型过滤器。实际写的时候你会发现，面经常被重复访问，因为一个面可能被多个壳引用，所以严谨的做法是配合索引或者去重集合。这个细节绝大多数入门材料都不提，但做面积统计的时候不算重会直接导致结果错得离谱。

3.2 句柄机制与内存，崩得最多的就是这里

OCC 里的对象分两类，管理方式完全不一样，混了就出事。

一类是继承自Standard_Transient的类，用Handle(Xxx)这种引用计数的智能指针包起来，比如Handle(Geom_Curve)、Handle(AIS_Shape)。这类对象你new出来交给 Handle 就行，绝对不要自己 delete，引用计数归零会自动回收。

另一类是TopoDS_Shape以及它衍生的各种形状类，它们本身就是轻量的“值”，内部靠一层共享的底层数据结构实现拷贝廉价。也就是说，你可以放心地把TopoDS_Shape拷贝来拷贝去、塞进容器、作为返回值，开销很小。它也没有对应的 Handle 版本。

真正的坑在这里：TopoDS_Shape拷贝廉价不代表底层数据不占内存。做批量处理的时候，每处理一个模型都应该显式清理不再需要的底层数据，否则内存曲线会一直往上爬。我遇到过一次跑两万个零件，跑到一千多个的时候内存直接爆掉，查了半天发现是没清理缓存。

3.3 容差：所有诡异问题的总根源

OCC 是基于容差的内核，不是精确算术。每个顶点、边、面都带一个容差值，默认精度常量是 1e-7。布尔运算能不能成功，很大程度上取决于参与运算的几何体之间的容差关系对不对得上。

我总结了两条实用原则，都是从翻车里总结出来的。

第一条，单位统一用毫米，尺寸控制在一毫米到一米这个量级。不要造一个尺寸 1e6 量级的模型，也不要做 1e-3 以下的东西。原因很直白：容差是绝对值，模型尺寸越大，相对精度越差；模型越小，1e-7 的容差就变得过大，布尔运算会误判两个面是重合的。

第二条，布尔失败先查容差，别急着改算法。可以先用BRepCheck_Analyzer检查参与运算的实体是否有效，再用BRepAlgoAPI_*的SetFuzzyValue适当放宽一点点容差，通常能救回来。放宽的标准是模型最小特征尺寸的千分之一以内，放太多会引入破面。

3.4 建模算法链：按构造、布尔、修饰三段走

用熟了你会发现 OCC 的建模类命名非常规整，基本可以按前缀分类。

构造类以BRepPrimAPI_和BRepBuilderAPI_为主：MakeBox、MakeCylinder、MakeSphere、MakePrism（拉伸）、MakeRevolution（旋转）、MakePipe（扫掠）。输入几何、输出形状，基本都是构造函数里完成，拿.Shape()取结果。

布尔类以BRepAlgoAPI_为主：Fuse（并）、Cut（差）、Common（交）。这里有个性能技巧必须提：如果你要连续减去十个孔，不要写十次 Cut 串起来，用一次 Cut，把主体放在Arguments()、十个孔全塞进Tools()，速度差别在大模型上是几倍的量级。

修饰类以BRepFilletAPI_和BRepOffsetAPI_为主：MakeFillet（圆角）、MakeChamfer（倒角）、MakeThickSolid（抽壳）。

不管用哪一段，结果都要验：

BRepCheck_Analyzer analyzer(resultShape); if (!analyzer.IsValid()) { // 处理失败分支，别硬往下走 }

这句判断看起来啰嗦，但省的是后面调试的时间。很多问题往下传三层才崩，崩的地方跟真正的错误点八竿子打不着。

3.5 可视化框架的组成关系

可视线这部分初学时最容易晕，因为类名一堆而且互相嵌套。实际结构是一条链：V3d_Viewer管渲染器和灯光，OpenGl_GraphicDriver是具体的渲染后端，V3d_View表示一个视口，AIS_InteractiveContext管场景里所有可交互对象，AIS_Shape把你的TopoDS_Shape包一层挂进场景。

初始化的顺序不能乱：先建 driver，用 driver 建 viewer，viewer 建 view，view 设置窗口和视口尺寸，最后建 context。有一处顺序错了，表现通常是编译通过、运行黑屏，然后你花半天怀疑显卡驱动。

注意：在无桌面环境下做模型预览或者批量出图，必须走离屏渲染路径并显式指定像素尺寸，别指望它能自动弹出一个窗口。这一点在服务端部署时尤其关键。

4. 从零做一个参数化法兰：一次完整走通

光看概念没用，这里用一个实际零件把整条链路串一遍。选法兰是因为它的结构简单、参数关系清楚、还天然包含“多个孔”这种批量布尔的场景，特别适合当第一个完整练习。

4.1 需求拆解与建模思路

需求是这样：给一组参数，自动生成一个法兰盘并导出成 STEP 文件。参数包括外径、内径、厚度、螺栓孔数量、分布圆直径、孔直径。

建模思路按顺序走：造外圆柱 → 造内圆柱 → 相减得到带中心孔的盘 → 循环在每个孔位造小圆柱 → 一次性全部减掉 → 校验 → 导出。

为什么不边造边减？因为十个独立的小圆柱丢进一次布尔，比十次单次布尔快得多，而且失败时的可回退性更好——你可以先把所有孔都造出来，检查一下有没有互相干涉，再统一执行。

4.2 参数取值与结构验算

我给一组具体数值，后面代码里都用这组：

先做约束验算，这一步是很多人跳过的，但如果不校验，参数一改就造出废件。外缘裕量 = (120 - 95)/2 - 5.5 = 7 mm，正数，外缘有余量。内缘裕量 = (95 - 60)/2 - 5.5 = 12 mm，也够。相邻孔中心角是 60 度，弦长 = 2 × 47.5 × sin(30°) = 47.5 mm，远大于孔径 11 mm，不会干涉。

体积的理论值：盘体 (π/4)×(120² - 60²)×16 ≈ 135716.8 mm³，六个孔 π/4 × 11² × 16 × 6 ≈ 9123.2 mm³，净体积约126593.6 mm³。这个数记下来，后面用来验算。

4.3 代码实现

核心部分不长，关键是圆柱的轴向定位。默认的圆柱是从原点沿 Z 轴正方向长，我习惯把它居中，这样后面装配和对称操作都方便。

#include <BRepPrimAPI_MakeCylinder.hxx> #include <BRepAlgoAPI_Cut.hxx> #include <BRepCheck_Analyzer.hxx> #include <GProp_GProps.hxx> #include <BRepGProp.hxx> #include <TopTools_ListOfShape.hxx> #include <cmath> TopoDS_Shape MakeFlange(double D, double d, double t, int n, double D1, double d1) { double halfT = t / 2.0; // 外圆柱，轴向居中 TopoDS_Shape outer = BRepPrimAPI_MakeCylinder( gp_Ax2(gp_Pnt(0, 0, -halfT), gp_Dir(0, 0, 1)), D / 2.0, t); // 内孔 TopoDS_Shape inner = BRepPrimAPI_MakeCylinder( gp_Ax2(gp_Pnt(0, 0, -halfT - 1.0), gp_Dir(0, 0, 1)), d / 2.0, t + 2.0); BRepAlgoAPI_Cut cutInner(outer, inner); TopoDS_Shape body = cutInner.Shape(); // 一次减掉所有孔：body 当参数，孔全部进工具列表 TopTools_ListOfShape arguments, tools; arguments.Append(body); for (int i = 0; i < n; ++i) { double angle = 2.0 * M_PI * i / n; gp_Pnt center(D1 / 2.0 * std::cos(angle), D1 / 2.0 * std::sin(angle), -halfT - 1.0); tools.Append(BRepPrimAPI_MakeCylinder( gp_Ax2(center, gp_Dir(0, 0, 1)), d1 / 2.0, t + 2.0)); } BRepAlgoAPI_Cut cutAll; cutAll.SetArguments(arguments); cutAll.SetTools(tools); cutAll.Build(); if (!cutAll.IsDone()) return TopoDS_Shape(); TopoDS_Shape result = cutAll.Shape(); BRepCheck_Analyzer analyzer(result); return analyzer.IsValid() ? result : TopoDS_Shape(); }

几个细节值得单独说。内孔和螺栓孔的圆柱高度都做成t + 2.0，并且起点往负方向偏 1 mm，这叫“过切”，目的是让刀具完全穿透上下表面，避免因浮点误差在表面留一层薄膜。这层薄膜用肉眼看几乎不存在，但会导致布尔结果显示成一个带内部空腔的实体，体积报告直接错掉，是最隐蔽的一类错误。

另外注意SetArguments和SetTools的用法与构造函数版本的差别：构造函数版本是两两运算，列表版本才是批量处理。

4.4 校验与导出

生成完先算体积，跟理论值 126593.6 对一下：

GProp_GProps props; BRepGProp::VolumeProperties(result, props); double v = props.Mass(); // 期望 126593.6 左右 double err = std::fabs(v - 126593.6) / 126593.6; // 实测下来误差在 1e-6 量级属于正常，超过 1e-3 就要查

实测结果一般会落在 126593.58 到 126593.62 之间，相对误差远小于千分之一，说明几何是对的。如果体积差得明显，八成是某个孔没减穿，或者两个孔的位置重叠了。

导出 STEP：

#include <STEPControl_Writer.hxx> #include <Interface_Static.hxx> Interface_Static::SetCval("write.step.unit", "MM"); Interface_Static::SetIVal("write.step.schema", 5); // 按需选协议版本 STEPControl_Writer writer; writer.Transfer(result, STEPControl_AsIs); writer.Write("flange.step");

单位和协议版本这两行必须显式设置，否则默认值可能和你的预期不一致，别人打开模型发现比例差了一千倍，就是这一步漏了。导出之后一定要用另一个工具打开看一眼，别只相信自己写的代码，这是我在项目里反复强调的习惯。

5. 常见问题与排查实录

5.1 编译和链接阶段的问题

链接报找不到符号，按顺序查三件事：库列表是不是漏了某个模块（不同功能分在不同TK前缀的库里，做可视化要额外链可视化那几个，做 STEP 读写要额外链数据交换那几个）；配置目录是不是指到了安装目录下的cmake子目录；Debug 与 Release 是不是混了。第三条最难查，因为报错信息看起来跟普通缺库一模一样。

配置阶段报找不到包，通常是把OpenCASCADE_DIR写成了安装根目录。它要的是包含配置文件的那一层，通常是根目录下的cmake文件夹。这一条我至少踩过三次。

还有一个隐蔽的：编译器版本和二进制包不匹配。运行时库版本对不上，编译能过，运行到某个特定功能才崩，而且崩的位置每次都不同。遇到这种“随机崩”，第一反应就应该是检查 ABI 一致性。

5.2 运行时的崩溃与逻辑错误

句柄相关的崩溃，特征通常是崩在析构阶段。原因基本是把局部对象里new出来的Standard_Transient派生对象直接delete了，或者对一个已经被回收的 Handle 继续访问。记住那句话：给 Handle 的对象，永远不要手动释放。

形状相关的错误更隐蔽。TopoDS_Shape有个IsNull()，但IsNull()为假不代表形状是有效的。空壳、无效的环、方向错误的面的组合，IsNull()都返回假。所以判断有效性的正确姿势永远是BRepCheck_Analyzer，不是IsNull()。

可视化黑屏，如果编译链接都正常，先查初始化顺序，再查渲染后端有没有正确创建，最后才怀疑显卡。顺序这一条占了黑屏原因的绝大多数。

5.3 布尔运算失败的典型场景

布尔失败是 OCC 使用中最常见的拦路虎，我把遇到的归成几类：

共面这种情况特别常见：你要在一个已经有一个面的位置再造一个面，两者完全重合，内核无法判断该保留哪一侧。做法是在建模阶段就让两者错开一点点，比如过切 1 mm，比事后补救省事得多。

5.4 一份可以贴在显示器边上的速查表

6. 学习路径安排与资料取舍心得

6.1 中文教程的正确用法

拿到一份中文教程，别从头抄到尾。我的用法是把它当索引用：先扫一遍目录，找到自己要做的那个功能对应哪几个类，然后带着这几个类名去翻官方类说明，看具体的参数意义，最后再回来看教程里的示例，把示例改造成自己的参数。

这个顺序很重要。先看示例会导致你只会照着改数字，一换场景就不会了；先看类说明又太枯燥，容易放弃。索引、说明、示例三步走，效率最高。

还有一点：遇到版本差异，以自己实际装的版本为准。教程里的代码跑不通，先别怀疑自己，去查一下这个类在你这个版本里有没有被标记为过时、有没有新的替代类。OCC 在 7.x 系列里做过不小的调整，很多老代码需要改写法才能编译。

6.2 分阶段目标与练习清单

我给自己的练习清单是这么排的，你也可以照这个顺序走。

第一阶段，一周内：跑通基础体构造、打印体积和包围盒、用遍历器统计面数和边数。目标是建立起“形状是数据结构不是黑盒”的感觉。

第二阶段，一个月内：做拉伸、旋转、扫掠各一个；做一次成功的布尔并、差、交；做一次圆角和倒角；做一次抽壳。每一个都要跑有效性检查，失败的要记录失败原因。

第三阶段，一到两个月：完整走一遍导入 STEP、遍历实体、识别某个特征、修改参数、导出 STEP。这一步做完，你已经能做实际的业务功能了。

第四阶段，持续：做容差实验——同一组布尔运算，把SetFuzzyValue从 0 调到 1e-3，观察成功率和结果的差异。这个实验做完，你对内核的理解会上一个台阶。

6.3 我踩过的三个认知误区

第一个误区：以为 OCC 有参数化能力。它没有。你给它的是具体的几何参数，不是“这个孔跟着那个尺寸走”的约束关系。要做参数化特征树，得自己在外面搭一层，把特征、参数、依赖关系、重建顺序全自己管。很多人一开始就想着做参数化 CAD，结果在这一层耗光了热情。

第二个误区：忽略容差，把它当成“高级话题”往后放。容差不是高级话题，是日常话题。你第一天做布尔就会遇到它。早点建立“所有几何运算都在容差范围内进行”的意识，能少走很多弯路。

第三个误区：想着把所有模块都编译上、所有功能都用上。实际上百分之八十的项目只用到构造、布尔、数据交换这三块，可视化都可能不需要。模块开得越多，依赖冲突的概率越高，编译时间越长。

6.4 关于“免费”这件事的几句实话

开源许可允许商业使用，这一点是可以确认的，但条款细节值得自己读一遍原文，尤其是动态链接和静态链接的要求不一样，改动了内核源码之后的分发义务也不一样。我的做法是把许可原文打印出来贴在工位上，遇到不确定的地方就翻。这不是小题大做，商业项目上因为许可问题返工的成本，比读一遍文档高几个数量级。

至于学习成本，说实话不低。但投入一两个月换一个能长期复用的几何内核能力，对做工业软件这条线的人来说，账是划算的。

我个人在实际项目里最深的一条体会是：别把 OCC 当成一个需要“学会”的库，把它当成一个需要“摸清脾气”的同事。它的文档能告诉你每个接口叫什么，但告诉不了你它在什么情况下会闹别扭。那些闹别扭的场合,基本都集中在容差、布尔、句柄这三件事上，把这三件事的规律摸出来，剩下的就是查手册的体力活。我到现在还会偶尔翻自己早几年记的失败案例笔记，那些笔记的价值比任何教程都高——建议你从第一个项目开始就记，记下每次失败的输入参数和最终解决办法，一年之后这份笔记就是你自己的中文教程。