C++/C#/Python 三种语言混用的真实代价，以及为什么在 CAA 生态下"多语言不是优势，是妥协"。
问题的起点
在出图审核工具的技术方案中，我们最初设计了三种语言的分工：
| 语言 | 职责 |
|---|---|
| C++ (CAA) | 插件框架 + 图纸解析 + UI |
| C# (.NET) | 规则引擎 + 检查算法 + 报告生成 |
| Python | 原型验证 + 数据分析（仅开发阶段） |
看起来很合理——每种语言做自己最擅长的事。但当我们深入 CAA 生态的实际约束后，发现这个架构存在严重的隐形成本。
三种统一方案的分析
| 方案 | 可行性 | 代价 |
|---|---|---|
| 全 C++ | ✅ 可行 | 规则引擎、JSON 处理、Excel/PDF 生成全部手写，开发效率低 |
| 全 C# | ❌ 不可行 | C# 不能编译为 CAA 原生 DLL，CATIA 无法直接加载 |
| C# COM Interop 全量 | ⚠️ 理论可行 | CATIA COM API 在 C# 中通过 Interop 调用极其脆弱 |
C# COM Interop 在 CATIA 中的实际表现
我们在 CatiaAIDemo 项目中尝试过 C# 调用 CATIA COM API。即便是简单的几何操作（创建点、画线），也频繁出现：
E_FAIL：接口方法签名版本不匹配RPC_E_SERVERFAULT：COM 线程模型冲突- GUID 硬编码导致的跨版本兼容问题
这些错误在生产级插件中不可接受。
纯 C++ 方案的可行性
经过评估，纯 C++ 完全可行：
| 原 C# 模块 | C++ 替代方案 | 成熟度 |
|---|---|---|
| JSON 解析 | nlohmann/json | header-only，业界标准 |
| 规则引擎 | C++ if-else + JSON 配置 | 逻辑简单，无技术难度 |
| Excel 导出 | COM Interop to Excel.Application | CATIA 环境自带 |
| PDF 导出 | libharu | MIT 协议，静态链接 |
结论
C++ 是 CAA 插件的硬性要求，C# 是效率选择。多语言不是选择出来的，是 CAA 生态逼出来的。 对于单人开发或追求零外部依赖的项目，纯 C++ 是更务实的选择。
*延伸阅读：出图审核工具：从 0 到 1 的技术方案*