diff --git a/AecDbEwEquipment-analysis.md b/AecDbEwEquipment-analysis.md
new file mode 100644
index 0000000..5eb0b17
--- /dev/null
+++ b/AecDbEwEquipment-analysis.md
@@ -0,0 +1,548 @@
+# AecDbEwEquipment 分析：内存、缺陷与性能
+
+> 目标：在动手改之前，把 `AecDbEwEquipment`（阀门/设备通用实体）的内存问题、潜在缺陷和性能热点列清楚，给出可分批落地的方案。
+>
+> 范围：`SourceCode/Code2026/inc/AecDbEwEquipment.h`（578 行）、`SourceCode/Code2026/CoreLibrary/AecDbEwEquipment.cpp`（14290 行）。关联的 `AecEqui::XPrimData`（`inc/EarThwormDef.h:2526`）、`AecDbEntityCommon` 的 2D/3D 缓存（`AecRxBase/AecDbEntityCommon.cpp`）只在必要时提及。
+>
+> 状态（2026-10-22）：仅分析，未改代码。行号以当前 `main` 为准。
+
+---
+
+## 1. 类职责与数据模型
+
+### 1.1 职责
+
+`AecDbEwEquipment` 继承 `AecDbEntityBase` + `AecMInterfaces`，是"阀门、设备"这类**参数化拼装体**的宿主：
+
+- 自身只存插入点 `m_ptInsert`、方向 `m_vtDir`、专业数据 `m_mapSpecXData`、两个图层软指针 `m_idDash` / `m_idCenter`、竖放标志 `m_bVert`
+- 几何是 `m_arSubPrimPtrs`（`CPtrArray`，元素是堆上的 `AecEqui::XPrimData*`），每个单元描述一个基本体（box / cylinder / cone / revolve / nozzle / extrude / Revit 组合 …）
+- 3D 显示时逐个 `Draw3dSolid()` 造 `AcDb3dSolid`，按 `m_bBoolSubtract` 分成并集/差集两组，做布尔后放进 3D 缓存
+- 2D 显示时按阀门类型画符号（25 个 `Draw*2d`），或把 3D 单元投影到平面（`PrimPorjectToPlan`）
+
+### 1.2 几何单元 `XPrimData`
+
+```cpp
+struct XPrimData {
+    short  m_eType;      // 基本体类型
+    PVOID  m_pData;      // 参数块（new byte[n] 或 new 具体结构体）
+    int    m_nSize;      // 参数块字节数
+    ...
+    std::vector<XPrimData*> m_Combins;  // 组合设备的子单元
+};
+```
+
+两个关键点，后文大量引用：
+
+| 事实 | 位置 | 影响 |
+| --- | --- | --- |
+| `~XPrimData()` 只删 `m_Combins`，**不删 `m_pData`** | `EarThwormDef.h:2539` | 删除 `XPrimData` 前必须手动 `releaseData()`，否则参数块全泄漏 |
+| `releaseData()` 按类型区分 `delete[]` / `delete` | `EarThwormDef.h:2544` | 释放方式与类型绑定，不能统一 `delete[]` |
+
+### 1.3 数据流
+
+```
+开图  dwgInFields:1693 ──► dwgInFieldsForXPrim:172（递归读 m_Combins）
+                        └─► subDMesh2NewSolid:3145（Revit 子网格 → 参数化单元）
+
+存盘  dwgOutFields:1807 ──► dwgOutFieldsForXPrim:239（递归写 m_Combins）
+
+绘制  Draw2d:2491 ──► MakeCurves:11063 ──► PrimPorjectToPlan:8314（逐单元投影）
+      Draw3d:3002 ──► Draw3dSolid:3905 ──► Draw3dSolid(XPrimData):3526（逐单元造体）
+                   └─► 布尔并/减 ──► Add3DBuffer
+
+导出  GetDraw2dables:2782 / GetDraw3dables:2928（克隆 + 投影/并体 + 写 BIM XData）
+```
+
+---
+
+## 2. 内存问题
+
+### 2.1 P0：`m_pGripAppData` 在 `dwgInFields` 里重复分配
+
+| 位置 | 代码 |
+| --- | --- |
+| 构造 `:1682` | `m_pGripAppData = new AecGripData[GRIP_MAXNUM];` |
+| `dwgInFields:1707` | `m_pGripAppData = new AecGripData[GRIP_MAXNUM];` ← 又分配一次，旧指针直接丢弃 |
+| 析构 `:1690` | `delete [] m_pGripAppData;`（只删最后一块） |
+
+`GRIP_MAXNUM` 为 256（`EarThwormDef.h:163`），`AecGripData` 含 `szTip[256]` + `szID[256]` + `szLockId[39]` + 3 个 `AcGePoint3d` + 1 个 `AcGeVector3d`，`sizeof` 约 1.2 KB。**每个设备实体开图即泄漏约 300 KB**，1000 个设备 ≈ 300 MB，且每次重开图纸累加。
+
+同一处还有两个次要泄漏：
+
+- `:1709` 读版本号失败、`:1712` 版本过高返回 `eMakeMeProxy` 时，新数组同样丢弃
+- `:1720` `pFiler->readString(&pszTmp)` 分配的字符串没有 `acutDelString(pszTmp)`（对比 `AecDbEwFitting.cpp:639` 的正确写法），每次开图泄漏一个 GUID 长度的小块
+
+**修复**：删掉 `:1707` 的重复分配（构造函数已经分配过）；`readString` 用完补 `acutDelString`。改动 3 行，收益最大。
+
+### 2.2 P0：析构函数不释放几何单元
+
+```cpp
+AecDbEwEquipment::~AecDbEwEquipment(void)      // :1686
+{
+    Clean3DBuffer();
+    Clean2DBuffer();
+    delete [] m_pGripAppData;
+}                                              // m_arSubPrimPtrs 完全没处理
+```
+
+`CPtrArray` 析构不会删除元素，`~XPrimData` 也不删 `m_pData`。所以**每个被销毁的设备实体，泄漏全部几何单元 + 参数块**。开图后关图、复制粘贴、`clone()` 的临时对象销毁，都走这条路。
+
+同类 `AecDbEwFitting` 的析构（`:584`）同样没处理它的子单元数组，属于同一批遗留写法。
+
+**修复**：析构里补 `FreeBuffer(m_arSubPrimPtrs);`（该函数已存在，见 2.3，需先修 2.3）。
+
+### 2.3 P0：`FreeBuffer(CPtrArray&)` 只释放数据块，不释放结构体
+
+```cpp
+void FreeBuffer(CPtrArray& arSubPrimPtrs)      // :1520
+{
+    for (...) {
+        AecEqui::XPrimData* pData = (AecEqui::XPrimData*)arSubPrimPtrs.GetAt(i);
+        if (pData != NULL) {
+            if (pData->m_nSize > 0)
+                delete[](byte*)pData->m_pData;   // 只删 m_pData
+        }
+    }
+    arSubPrimPtrs.RemoveAll();                    // 结构体本身没删
+}
+```
+
+被 `copyFrom:2181` 调用，于是 `copyFrom` 每次都泄漏被覆盖的那批 `XPrimData` 结构体。修 2.2 时会连带放大这个问题。
+
+另外这里无条件 `delete[](byte*)`，而 `releaseData()` 是按类型区分 `delete[]` / `delete` 的。`byJson`（`:820`）用 `new PVOID[]` 分配，属于数组，`delete[]` 恰好对；但若将来有类型用标量 `new`，这里就是堆损坏。**建议统一改成 `pData->releaseData(); DELETE_PTR(pData);`**，让释放规则只有一处。
+
+### 2.4 P0：`subDMesh2NewSolid()` 删错元素，且泄漏
+
+```cpp
+void AecDbEwEquipment::subDMesh2NewSolid()     // :3145
+{
+    CPtrArray ar, subDs;
+    std::vector<int> idxs(0);
+    for (int i(0); i < m_arSubPrimPtrs.GetCount(); ++i) {
+        AecEqui::XPrimData *p = (AecEqui::XPrimData *)m_arSubPrimPtrs[i];
+        if (p->m_eType == AecEqui::kSubDMesh) {
+            idxs.push_back(i);          // 记录的是"原始下标"
+            subDMesh2NewSolid(p, ar);
+        }
+    }
+
+    for (size_t i(0); i < idxs.size(); ++i)
+        m_arSubPrimPtrs.RemoveAt(i);    // ← 用的是 i，不是 idxs[i]
+    ...
+}
+```
+
+两个错误叠加：
+
+1. **删错元素**：`RemoveAt(i)` 删的是第 0、1、2… 个元素，而不是记录的 SubDMesh 下标。只要有一个 SubDMesh，就会把**第一个**正常单元删掉，SubDMesh 本身反而留着（后续 `Draw3dSolid` 对 `kSubDMesh` 是 `assert(0)`）。
+2. **泄漏**：`RemoveAt` 只摘指针，被摘掉的 `XPrimData` 及其 `m_pData` 全部泄漏。
+
+正确写法是按下标**从大到小**删，并先 `releaseData()` + `DELETE_PTR`。
+
+这条只在"图纸里含 Revit 子网格单元"时触发，但一旦触发就是几何丢失，属数据正确性问题。
+
+### 2.5 P1：`RemoveSubPrimObj` / `RemoveSubPrimObjByID` 不调 `releaseData()`
+
+`:4276` 和 `:4291` 都是 `DELETE_PTR(pSolid)`，而 `~XPrimData` 不删 `m_pData`。删一个单元泄漏一个参数块（box/cylinder 几百字节，Revit 单元可能几十 KB）。
+
+### 2.6 P1：`GetDraw2dables` 克隆后丢弃
+
+`:2843` 对 2D 缓存里每个实体 `clone()`，然后：
+
+- `AcDb3dSolid` → `OrthoProjected3DSolid` 后 `continue`（`:2850`）
+- `AcDbSubDMesh` → `OrthoProjected3DSubMesh` 后 `continue`（`:2857`）
+
+`OrthoProjected3DSolid` 只是把传入实体喂给 HLR 收集器（`CoreCommand/HlrCommands.cpp:214`），**不接管所有权**。这两条 `continue` 的克隆体全部泄漏，每次调用泄漏 N 个 solid。
+
+### 2.7 P1：剖切相关的克隆泄漏
+
+| 位置 | 问题 |
+| --- | --- |
+| `GetSectionDraw:12691` | `return OldGetSectionDraw(...)` 时没有 `delete pFit`（`:12677` 克隆的整份设备） |
+| `OldGetSectionDraw:12620` | 逐个子实体 `clone()`，只对 `AcDb3dSolid` 做了投影，非 solid 的克隆体既不进结果也不释放 |
+| `OldGetSectionDraw:12609` | `GetDraw3dables(arSubPtrs,false)` 产出的整组克隆从头到尾没释放 |
+
+剖切是低频操作，但一次剖切可能泄漏几十个实体。
+
+### 2.8 P1：`GetClosestPointToSUbPrim` 泄漏 region，并写库
+
+```cpp
+AcDbObjectId idSH = CoreTools::AddToModelSpace(pSolid);   // :3986 把临时体写进模型空间
+...
+pFace->convertToRegion(regions);                          // :4032 新建 region
+for (...) { ... }                                         // regions 里的对象从不释放
+delete pEnt;                                              // :4049 只删了 explode 出来的本体
+```
+
+两个问题：
+
+1. `convertToRegion` 产出的 region 全部泄漏
+2. 为了算一个最近点，把临时 solid **加进当前图纸的模型空间**再 erase。这会触发数据库事务、undo 记录、反应器，是明显的性能与副作用问题
+
+### 2.9 P2：`SortAecComplexCurves` 丢弃空曲线
+
+`:11230` 先把非空曲线挑进 `std::vector`，然后 `arPrimCplPtrs.RemoveAll()` 再回填。**空曲线指针被直接丢掉，没有 delete**。`PrimPorjectToPlan:8507` 每次都调用，投影为空的单元越多，泄漏越多。
+
+### 2.10 P2：`ByJson` 失败路径泄漏
+
+`:12853` `new XPrimData`，`byJson` 返回 false 时不入数组也不删除，连带已解析出来的 `m_pData` 一起泄漏。另外 `ByJson` 没有先清空 `m_arSubPrimPtrs`，对已有几何的对象再导入会叠加重复单元。
+
+### 2.11 P2：`MakeBlockRefSet` 失败路径泄漏
+
+`:12540` `new AcDbBlockTableRecord`，若 `getBlockTable` 失败（`:12559`）或 `pTbl->add` 失败，`pRec` 既不关闭也不删除。`appendAcDbEntity` 失败时（`:12552`）实体也没关闭。
+
+### 2.12 内存问题汇总
+
+| 级别 | 问题 | 位置 | 触发频率 | 单次量级 |
+| --- | --- | --- | --- | --- |
+| P0 | 夹点数组重复分配 | `:1707` | 每个实体每次开图 | ~300 KB |
+| P0 | 析构不释放几何单元 | `:1686` | 每个实体销毁 | 全部参数块 |
+| P0 | `FreeBuffer` 不删结构体 | `:1520` | 每次 `copyFrom` | N 个结构体 |
+| P0 | `subDMesh2NewSolid` 删错+泄漏 | `:3159` | 含 SubDMesh 的图 | N 个单元 + 几何错乱 |
+| P1 | `RemoveSubPrimObj*` 漏 `releaseData` | `:4276` `:4291` | 编辑删除单元 | 1 个参数块 |
+| P1 | `GetDraw2dables` 克隆泄漏 | `:2850` `:2857` | 2D 导出/剖切 | N 个 solid |
+| P1 | 剖切克隆泄漏 | `:12691` `:12620` | 每次剖切 | N 个实体 |
+| P1 | `readString` 未释放 | `:1720` | 每次开图 | 小 |
+| P1 | `convertToRegion` 泄漏 | `:4032` | 最近点查询 | N 个 region |
+| P2 | 空曲线丢弃 | `:11240` | 每次 2D 投影 | 小 |
+| P2 | `ByJson` / `MakeBlockRefSet` 失败路径 | `:12853` `:12540` | 异常路径 | 小 |
+
+---
+
+## 3. 潜在缺陷
+
+### 3.1 P0：存盘时把组合设备的子单元清空
+
+```cpp
+void dwgOutFieldsForXPrim(AecEqui::XPrimData *pSolid, ...)   // :239
+{
+    ...
+    if (CurrentVer >= 5)
+    {
+        // 做一下容错
+        if (pSolid->m_eType != AecEqui::kRevitCombination ||
+            pSolid->m_eType != AecEqui::kRevitCombination)   // ← 恒真
+            pSolid->m_Combins.clear();
+        ...
+    }
+}
+```
+
+`x != A || x != A` 永远为真（第二个条件显然是想写 `kCombination`）。结果：
+
+- **任何带 `m_Combins` 的单元，在存盘前子单元被清空**，写出去的就是 0 个
+- 因为是就地 `clear()`，**当前内存里的对象也被破坏**，存完盘再画就没了
+- 这段位于 `const` 的 `dwgOutFields` 调用链上，等于在"只读"函数里改数据
+
+影响面取决于图纸里是否还有 `kCombination` 单元（Revit 组合走的是 `kRevitCombination`，数据在 `m_pData` 里，不受影响）。但这段逻辑本身是明确的错误，应先修成 `&&`，并且把"容错"挪到读入或创建时，不要在存盘路径里改数据。
+
+### 3.2 P1：`subErase` 里 `Find` 当布尔用
+
+```cpp
+if (eSubType == eValve || sName.Find(_T("阀")) != -1 || sName.Find(_T("接头")))   // :2119
+```
+
+`CString::Find` 找不到返回 `-1`，非 0 即真，所以**第三个条件恒真**。整句等价于"永远是阀门"，删除任何设备都会走合并管线那段逻辑（`GetInterface` + `PushGripMessage`）。应写成 `!= -1`。
+
+### 3.3 P1：`DrawHandFlg` 用 `==` 赋值
+
+```cpp
+if (nVt == 1) sFlag = _T("M");
+else if (nVt == 2) sFlag = _T("G");
+else sFlag == _T("Y");        // :2656 应为 =
+```
+
+液动（3）时文字为空，画出来是空标注。另外这里直接取 `GetInterface(0)` / `GetInterface(1)`，接口不足 2 个时 `inf2` 是默认值，`distanceTo` 为 0、`normalize()` 得到零向量，后续 `angleTo` 结果不可信。
+
+### 3.4 P1：`ProcessHlrResult` 在遍历中删 map 元素
+
+```cpp
+for (; it != _preAr.end(); ++it)
+{
+    if (AcDbRegion::cast(it->first))
+        _preAr.erase(it);        // :13133 迭代器失效，下一轮 ++it 是 UB
+}
+```
+
+应改为 `it = _preAr.erase(it);`。这是典型的偶发崩溃点（容器元素少时不容易复现）。
+
+### 3.5 P1：`GetSectionDraw` 返回值取反
+
+```cpp
+int nCount = arRegionPtrs.length();
+GetSectionDraw(plan, vtTo, arRegionPtrs);
+int nCoundPre = arRegionPtrs.length();
+return (nCount - nCoundPre);      // :12762 顺序反了
+```
+
+返回的是"调用前 − 调用后"，恒为 0 或负数。若调用方用它判断"是否剖到东西"，判断必然失败。
+
+### 3.6 P1：`HLR_CALC` 标志会被存进图纸
+
+`Draw3d:3009` 一旦读到 `HLR_CALC` 为真就直接返回，什么都不画。这个标志由 `PreprocessForHlr:13204` / `:13360` 置真、`ProcessHlrResult:13107` 复位。
+
+但 `m_mapSpecXData` 的序列化（`AecRxBase/AecDbObjXDataMap.cpp:2034`）是**全量写**，没有任何过滤。所以只要在"置真之后、复位之前"存盘（剖切过程中保存、崩溃、取消），标志就会留在 DWG 里，**下次开图这个设备在 3D 里永久不可见**。
+
+建议：`HLR_CALC` 这类纯运行时标志不要进 `m_mapSpecXData`，或序列化时按 key 白名单/黑名单过滤。
+
+### 3.7 P1：`GetInterface` 两个重载单位不一致
+
+| 重载 | 位置 | 是否乘 `dUnit`（米制 0.001） |
+| --- | --- | --- |
+| `GetInterface(int, AecInterface&)` | `:3285` | 是（`inf.dSize1 = pNoze->dVal1 * dUnit`） |
+| `GetInterface(AcArray<AecInterface>&)` | `:3224` | **否**（直接 `pNoze->dVal1`） |
+
+米制图纸里，同一份数据经两个入口读出来的接口尺寸差 1000 倍。`Draw*Vlv2d` 用下标版，`subErase` / `PreprocessForHlr` 用数组版，两边算出来的东西对不上。
+
+### 3.8 P1：`copyFrom` 漏拷字段
+
+`:2174` 只拷了 `m_mapSpecXData` / `m_nInfActive` / `m_ptInsert` / `m_vtDir` / 几何单元，**没有拷 `m_bVert`、`m_idDash`、`m_idCenter`**。复制粘贴一个竖放阀门，粘贴出来是横放的；两个图层软指针也丢了（虚线和中心线会跑到默认图层）。
+
+### 3.9 P2：`MakeBlockRefSet` 的范围累加逻辑错
+
+```cpp
+for (...) {
+    pEnt = (AcDbEntity*)arEntPtrs.at(i);
+    if (!AcDbBlockReference::cast(pEnt))
+        pEnt->getGeomExtents(extAdd);
+    if (isValidExtents(ext))        // :12522 判断的是累加器，不是本次结果
+        ext.addExt(extAdd);
+}
+```
+
+- 第一轮 `ext` 还是默认（空）状态，`isValidExtents(ext)` 为假 → **第一个实体的范围永远加不进去**
+- 若 `pEnt` 是块参照，`extAdd` 保持上一轮的旧值，会被重复累加
+- 若整个循环没加进任何范围，`ptIns` 由默认范围算出，块原点落在原点而不是设备位置
+
+应改成 `if (isValidExtents(extAdd)) ext.addExt(extAdd);`，块参照分支直接 `continue`。
+
+### 3.10 P2：`byJson` 的 `m_pData` 尺寸对不上
+
+```cpp
+p->m_nSize = it->value.GetInt();          // 字节数（来自 __nSize__）
+GEO2JSON::binary br(it->value);
+p->m_pData = new PVOID[br._len];          // 按 PVOID 个数分配
+::memcpy(p->m_pData, br._data, sizeof(PVOID) * br._len);   // :820
+```
+
+分配长度取决于 `br._len`，使用长度取决于 `m_nSize`，两者来自不同字段。JSON 被改过或版本不一致时就会越界读写。应按 `m_nSize` 分配并校验 `sizeof(PVOID)*br._len >= m_nSize`。
+
+### 3.11 P2：开图读入没有边界校验
+
+`dwgInFieldsForXPrim:172`：
+
+- `readInt32(&nSize)` 后直接 `new byte[pSolid->m_nSize]`（`:193`），负值或超大值都没有检查（负值转 `size_t` 会申请巨大内存）
+- `readBytes` 的返回值没有检查
+- `m_Combins` 是**递归**读（`:227`），没有深度上限，损坏的图纸可以打爆栈
+
+同类的 `AcDbX3dSolid` 阶段一、二已经补过类似的防护，这里可以照搬。
+
+### 3.12 P2：`PreprocessForHlr` 的"对面"被变换了两次
+
+```cpp
+AcGeMatrix3d mat4(mat3.inverse());        // mat3 = 沿截面法向平移 -H/2
+for (...) {
+    AcDbEntity *pNew = (AcDbEntity*)pEnt->clone();
+    pNew->transformBy(mat4);
+    pNew->transformBy(mat4);              // :13353 又乘一次
+    _other.append(pNew);
+}
+```
+
+原实体在 `-H/2` 位置，克隆体被移到 `+H` 位置（两次 `+H/2`），两侧不对称。除非这是刻意做的"厚度补偿"，否则应只乘一次。建议拿一个剖切样例对照确认。
+
+### 3.13 P2：`GetBodyBox` 恒返回 `TRUE`
+
+`:4205` 无论有没有取到实体都 `return TRUE`；且 `ar3D` 引用在 `Draw3d` 之前就绑定了（`:4207`）。当前 `Get3DBuffer()` 返回成员引用，重新填充不会换对象，所以能工作；但如果哪天改成返回副本就会静默失效。返回值也应反映实际结果。
+
+### 3.14 P2：`clearGeoBuffer()` 是空实现
+
+`:12861` 函数体只有 `AssertWriteEnabled();`。`PipelineCmd/EquipmentMakeDlg.cpp` 有 8 处调用，本意应该是清掉 2D/3D 缓存（`Clean2DBuffer` / `Clean3DBuffer`）。现在是"调了没反应"，改了参数后旧几何还在。
+
+### 3.15 P2：`booleanOper` 的所有权写法在本文件里自相矛盾
+
+同一文件里两种写法并存：
+
+| 位置 | 写法 | 若 SDK 会删除入参 | 若 SDK 不删除入参 |
+| --- | --- | --- | --- |
+| `:3774` | `booleanOper(...); DELETE_PTR(p);` | 二次释放 | 正确 |
+| `:3867` `:3964` | `booleanOper(...)` 后统一 `deleteArrayVoidPtrs` | 二次释放 | 正确 |
+| `:2964` | `booleanOper(kBoolUnite, pSolid)`，克隆体不再处理 | 正确 | 每次泄漏一个克隆 |
+
+也就是说：**无论 SDK 语义是哪一种，这三处至少有一处是错的**。需要先用最小样例（两个 box 做 unite，然后只删第二个）在调试版 + Application Verifier 下确认，再统一写法。这条不确认，2.6 和 2.7 的修复方式都不好定。
+
+### 3.16 其他
+
+- `GRIP_MAXNUM` 在两处定义：`EarThwormDef.h:163` 是 256，`AecWPipe.h:231` 是 24。当前 `AecWPipe.h` 没有被包含，暂时没冲突；一旦谁把它引进包含链，`m_pGripAppData` 的分配与使用边界就会不一致
+- `ReadFromFile:4843` 的 `Adesk::Int32 id = ::_time32(NULL);` 是死变量，实际用的是 `++pX->m_nID`，同一秒导入多个单元时 ID 可能重复
+- `Draw2d:2498` 的 `if (dc.IsDragging()) { /*return*/ }` 是空壳，拖拽时仍然读旧 2D 缓存，显示滞后一帧
+
+---
+
+## 4. 性能
+
+### 4.1 3D 绘制链路
+
+`Draw3d:3002` 每次调用：
+
+1. `DrawInfArrow` → `GetInterface(arInfs)` → 每个管嘴一次 `GetInfFaceInf`
+2. 有 3D 缓存就直接画缓存（快）
+3. 没有缓存 → `Draw3dSolid:3905`：逐单元 `Draw3dSolid(XPrimData)` 造体（每个单元一次 `acisIn`/`createXxx`），有差集时再做一轮并集 + 一轮差集
+4. `BoolUnit3DBuffer(0.001)`：米制时把缓存里每个 solid 再 `transformBy` 一次
+5. 逐个 `setTransparency`
+6. `Draw3DBuffers`
+
+成本主要在 3：N 个单元 = N 次造体 + (N−1) 次布尔，与 `AecDbX3dPart` 的结论一致。
+
+### 4.2 P0：拖拽时缓存不清理，且每帧全量重建
+
+```cpp
+if (!dc.IsDragging())          // :3036
+{
+    if (Has3DBuffer()) { 画缓存; return; }
+}
+Draw3dSolid(&dc, nColor);      // :3062 拖拽时每帧都走到这里
+```
+
+而 `Add3DBuffer`（`AecDbEntityCommon.cpp:146`）只是 `append`，**不清理已有内容**。于是拖拽过程中：
+
+- 每帧重新造 N 个 solid
+- 每帧往 3D 缓存里**再追加** N 个
+- `Draw3DBuffers` 把缓存里所有实体都画一遍
+
+第 k 帧要造 N 个体、画 k×N 个体。内存随帧数线性涨、帧率随帧数线性掉，拖一次长距离夹点就能看到明显卡顿和内存上冲。
+
+这是当前最值得修的性能问题。可选做法（按改动量排序）：
+
+1. 进入拖拽前 `Clean3DBuffer()`，拖拽结束后再清一次 —— 一行改动，先止住缓存膨胀
+2. 拖拽时画包围盒/线框（用 `GetInfFaceInf` 那套参数直接算 bbox），不造 ACIS
+3. 拖拽时只对缓存里的 solid 施加增量矩阵（`transformBy(delta)`），不重建
+
+### 4.3 P1：2D 符号绘制触发 3D 布尔
+
+11 处 `Draw*Vlv2d` 里调 `GetBodyBox(ext)`（`:5020` `:5189` `:5357` `:5512` `:5675` `:6307` `:6492` `:6654` `:6816` `:6996` `:7147`），而 `GetBodyBox:4205` 在没有 3D 缓存时会 `Draw3d` —— 也就是**为了画一个 2D 阀门手柄的方向，把所有单元造一遍体再做布尔**。
+
+`Draw2d` 本来就是轻量路径（平面符号），这条依赖把它变成了重路径。设备数量多、缩放频繁时开销明显。
+
+建议：给 `XPrimData` 增加一个按参数解析计算 bbox 的函数（box/cylinder/cone/nozz 这几种占绝大多数，参数都在 `m_pData` 里，`GetInfFaceInf` 已经在做类似的事），2D 路径只算参数 bbox，不碰 ACIS。
+
+### 4.4 P1：`GetInterface` 每次 `acedGetVar` + 临时实体
+
+- `:3237` 和 `:3300` 各调一次 `acedGetVar("INSUNITS")`，而 `GetInterface` 在绘制、夹点、osnap、剖切里共 67 处调用，很多在循环内。`INSUNITS` 是数据库级常量，可以缓存（`CoreTools::IsMetersUnit()` 已有类似封装）
+- `GetInfFaceInf` 每个面调两次 `GetTransformbyXform`（`:12160` `:12225`），每次都要 `new`/构造临时 `AcDbLine` / `AcDbPoint` 再走 `TransformEntity`。一个 6 面 box = 12 个临时实体；夹点显示时每个管嘴都要算
+- 建议：把"单元 → 世界矩阵"提成一个函数，一次算好，`GetInfFaceInf` / `GetTransformbyXform` 都复用它
+
+### 4.5 P1：`GetDraw2dables` 每次建 `*U` 块 + 跑 HLR
+
+`:2909` 调 `CKTCadUtility::CreateBlockTableRecord(ar, ptIns, NULL, ...)`，`pszBlk == NULL` 时会在当前图纸里**新建一个匿名块表记录**（`KTCadUtility.cpp:537`）。也就是说一次"取 2D 图形"的查询操作会往 DWG 里写数据：块表增长、undo 记录、文件变大。
+
+同时 `OrthoProjected3DSolid` 走的是完整 HLR（`HlrCommands.cpp:214`），每个 solid 一次。
+
+导出场景可以接受，但若被绘制路径复用就不合适。建议：
+
+- 只读查询走"投影曲线直接返回"，不建块
+- 需要块时由调用方决定，函数只负责给实体
+
+### 4.6 P1：开图路径
+
+`dwgInFields:1791` 无条件 `subDMesh2NewSolid()`，对每个 `kSubDMesh` 单元做一次 `ParseRevitFamily::parseJson`（`:3142`）。Revit 族转来的设备，这一步是开图耗时的大头之一，而且结果只用于显示。
+
+可以照 `AecDbX3dPart` 的做法改成惰性：开图只记标志，首次绘制/取几何时再解析。前提是先修 2.4（现在的删除逻辑会把数组搞错）。
+
+### 4.7 度量建议
+
+| 指标 | 位置 | 目的 |
+| --- | --- | --- |
+| `Draw3dSolid(XPrimData)` 调用次数 / 累计耗时 | `:3526` | 确认造体占比 |
+| `booleanOper` 次数 / 累计耗时 | `:3867` `:3964` | 确认布尔占比 |
+| 3D 缓存长度峰值 | `Draw3d:3036` | 验证 4.2 的膨胀 |
+| `GetBodyBox` 触发的 `Draw3d` 次数 | `:4205` | 验证 4.3 |
+| `GetDraw2dables` 建块次数 | `:2909` | 验证 4.5 |
+| 开图总时长 / `subDMesh2NewSolid` 时长 | `:1791` | 验证 4.6 |
+
+场景：单设备拖拽夹点、全图缩放、图层冻结后重生成、剖切、2D 导出。
+
+---
+
+## 5. 优化方案（分批）
+
+### 5.1 第一批：内存与正确性（不改接口、不改格式）
+
+| # | 改动 | 位置 | 风险 |
+| --- | --- | --- | --- |
+| 1 | 删掉 `dwgInFields` 里的重复分配，`readString` 补 `acutDelString` | `:1707` `:1720` | 低 |
+| 2 | 析构补 `FreeBuffer(m_arSubPrimPtrs)` | `:1686` | 低（依赖 #3） |
+| 3 | `FreeBuffer(CPtrArray&)` 改为 `releaseData()` + `DELETE_PTR` | `:1520` | 低 |
+| 4 | `subDMesh2NewSolid` 按下标倒序删除并释放 | `:3159` | 中（涉及几何正确性，需样例图） |
+| 5 | `RemoveSubPrimObj*` 补 `releaseData()` | `:4276` `:4291` | 低 |
+| 6 | `subErase` 的 `Find` 补 `!= -1` | `:2119` | 低（行为会变，需回归删除阀门） |
+| 7 | `DrawHandFlg` 的 `==` 改 `=` | `:2656` | 低 |
+| 8 | `ProcessHlrResult` 改用 `it = erase(it)` | `:13128` | 低 |
+| 9 | `copyFrom` 补 `m_bVert` / `m_idDash` / `m_idCenter` | `:2174` | 低 |
+| 10 | `GetSectionDraw` 返回值改 `nCoundPre - nCount` | `:12762` | 低（需确认调用方语义） |
+| 11 | `clearGeoBuffer` 实现为清 2D/3D 缓存 | `:12861` | 低 |
+
+这一批做完，开图内存和几个明确的逻辑错误就都清掉了，且不触碰存储格式。
+
+### 5.2 第二批：`m_Combins` 存盘清空（需要确认影响面）
+
+| 步骤 | 内容 |
+| --- | --- |
+| 1 | 统计现有图纸里 `kCombination` 单元的实际使用（与阶段三那次一样，先看数据） |
+| 2 | 修 `:279` 的恒真条件为 `!= kRevitCombination && != kCombination` |
+| 3 | 把"容错清理"从 `dwgOutFields` 挪到 `dwgInFields` 读完之后 |
+| 4 | 用含组合设备的样例做"存盘→重开→几何完整"验证 |
+
+若确认图纸里已无 `kCombination`，可以只做 2、3，不做数据迁移。
+
+### 5.3 第三批：性能（先量后改）
+
+| 优先级 | 改动 | 预期 |
+| --- | --- | --- |
+| 高 | 拖拽时清缓存 + 简化显示（4.2） | 拖拽帧率、内存峰值 |
+| 高 | 2D 路径改用参数 bbox，不触发 3D（4.3） | 2D 重生成、缩放 |
+| 中 | `INSUNITS` 缓存 + 单元矩阵复用（4.4） | 夹点、osnap |
+| 中 | `GetDraw2dables` 不建块（4.5） | 导出、剖切、DWG 体积 |
+| 低 | `subDMesh2NewSolid` 惰性化（4.6） | 开图 |
+
+### 5.4 需要先确认的事
+
+1. `booleanOper` 是否删除入参（3.15）—— 决定 2.6 / 2.7 怎么修
+2. `GetSectionDraw` 的返回值调用方到底期望什么（3.5）
+3. `PreprocessForHlr` 的 `mat4` 双次变换是否刻意（3.12）
+4. `kCombination` 单元的实际存量（5.2）
+
+---
+
+## 6. 风险与验证清单
+
+| 改动 | 验证方式 |
+| --- | --- |
+| 夹点数组 / 析构释放 | 打开含 1000+ 设备的图纸，任务管理器看私有字节；关图后应回落 |
+| `FreeBuffer` 改 `releaseData` | 各类单元（box/cylinder/cone/Revit/组合）各删一个，确认无崩溃 |
+| `subDMesh2NewSolid` | 含 SubDMesh 的样例图，开图后单元数量与类型正确，绘制不缺体 |
+| `subErase` | 删除阀门/接头/普通设备各一次，确认只有阀门走合并管线 |
+| `HLR_CALC` | 剖切过程中保存再重开，设备 3D 仍可见 |
+| `copyFrom` | 复制粘贴竖放阀门，方向与图层保持 |
+| 拖拽优化 | 拖夹点 10 秒，内存不涨、帧率稳定；松手后几何位置正确 |
+| 2D bbox | 各阀门 2D 符号方向、手柄位置与改前一致 |
+
+本仓库没有单元测试，验证只能靠"编译 + CAD 内实测"。编译范围按既有约定：Debug + R190，只编 `AecRxBase`、`CoreLibrary_BAL_REMOTE`、`CoreCommand_BAL_REMOTE`、`CoreImplement`。
+
+---
+
+## 7. 明确不做
+
+- 不改 `XPrimData` 的存储布局和 `kCurrentVersionNumber`（会带来新老插件不兼容，与 `AcDbX3dSolid` 阶段三取消的理由一致）
+- 不把 2D 符号系统（25 个 `Draw*2d`）重构成数据驱动，收益不明确、回归面太大
+- 不动 `AecDbEwFitting` / `AecDbHvacFitting` 等同类实体，除非确认它们的同一批写法也要一起改
+
+---
+
+## 8. 实施顺序
+
+1. 第一批 1~5（内存），单独一个 PR，可独立验证
+2. 第一批 6~11（逻辑），单独一个 PR
+3. 确认 5.4 的四个问题
+4. 第二批（`m_Combins`），视存量决定是否做
+5. 第三批按 4.7 度量结果排序，一项一个 PR