二次开发绕不开的第一个决策：用官方 CAA 框架写原生插件，还是用 COM 桥接快速验证？两者的代价完全不同。
为什么这是个问题
CATIA 提供两套二次开发接口：
- CAA（Component Application Architecture）：官方原生框架，用 C++ 写，编译进 CATIA 进程，性能与稳定性最好。
- COM Automation：通过
CATIA.Application对外暴露的自动化接口，C# / Python 都能调，上手快。
表面上 COM 更友好——不用配复杂的 CAA 编译环境，几行代码就能驱动 CATIA。但当我们把视角从"demo"拉到"生产级插件"，差异就出来了。
三种方案的可行性对比
| 方案 | 可行性 | 代价 |
|---|---|---|
| 纯 CAA C++ | ✅ 官方支持，最稳 | 开发效率低，环境搭建门槛高 |
| 纯 C# COM | ⚠️ 理论可行 | CATIA 不加载 .NET 插件，只能通过外部进程调用 |
| C# COM Interop 全量 | ⚠️ 脆弱 | GUID 硬编码、接口签名版本依赖、线程模型冲突 |
COM Interop 在真实项目中的表现
我们在实验项目里用 C# 调用 CATIA COM API，即便是简单的几何操作（创建点、画线），也频繁遇到：
E_FAIL：接口方法签名版本不匹配RPC_E_SERVERFAULT：COM 线程模型冲突- GUID 硬编码导致的跨版本兼容问题
这些错误在 demo 阶段可以忍，在交付给客户的插件里不可接受。
我们的结论
CAA C++ 是生产级插件的硬性要求，COM 适合做原型验证和轻量自动化脚本。
一个务实的组合是：
- 用 COM + Python/C# 快速验证想法、做数据处理类小工具；
- 用 CAA C++ 写需要随 CATIA 启动、长期稳定运行的正式插件。
多语言不是"选择出来的优势"，而是被生态逼出来的分工。对于追求零外部依赖、单人开发的项目，纯 C++ 反而更省心。
*延伸阅读：为什么最终选了纯 C++ · COM 桥接让 AI 操控 CATIA 的实验*