[LOW] Array 构造函数错误路径字符串拼接可优化

问题分析：

• 第 97-99 行：使用 + 操作符拼接字符串，会产生多个临时对象

std::string errMsg = "Array creation failed at index " + std::to_string(i) +
    ", requested count=" + std::to_string(count) +
    "; the acquire handle likely holds fewer resources than count";

• 这在错误路径（很少发生）上影响很小，但可使用更高效的方式

建议修复： 使用 std::ostringstream 或 fmt::format（如果可用）优化字符串拼接。

说明：这是微优化，在错误路径上影响不大。

include/ccu/ccu_array.hpp:97

同步刷新代码仓中的接口资料

[LOW] HcommCcuVariableAlloc 未包裹异常处理

第 353 行：CCU_CHK_RET(CcuAllocVarEventRes(...)) 调用链最终到达 resMap_.emplace(newHandle, std::move(res))，若 emplace 抛 bad_alloc，异常会穿越 HcommCcuVariableAlloc（extern C 函数）到达调用方。

问题分析：

• 同文件中 HcommCcuKernelRegister 使用 CCU_EXCEPTION_HANDLE_BEGIN/END 包裹可能抛异常的调用；CcuInstanceMgr::CreateByResDescs 使用 EXCEPTION_CATCH 包裹 emplace。HcommCcuVariableAlloc / HcommCcuEventAlloc 均未做同等防护，风格不一致。
• C ABI 函数抛异常是未定义行为（C 调用方无法 catch），bad_alloc 虽罕见但非不可能。

建议修复： 用 CCU_EXCEPTION_HANDLE_BEGIN/END 包裹 CcuAllocVarEventRes 调用，失败时返回 CCU_E_INTERNAL。HcommCcuEventAlloc 同理。

[LOW] GetInstance 边界检查逻辑可简化

问题分析：

• 第 31 行：if (devLogicId < 0 || static_cast<uint32_t>(devLogicId) >= MAX_MODULE_DEVICE_NUM)
• 这个逻辑是正确的（负值不会被 cast 掩盖），但 static_cast<uint32_t> 的使用略显复杂
• 可读性稍差，且容易让人误以为负值会有问题

建议修复： 简化为更直观的表达方式，或保持原样（这是代码风格问题，不影响功能）。

src/base_comm/resources/ccu/ccu_instance/ccu_var_event_res_mgr.cc:31

[LOW] ReturnToPool 不合并相邻空闲块

第 70 行：pool.emplace_back(info.startId, info.num); 将归还的资源块直接追加到 pool 末尾，不检查是否与现有空闲块相邻可合并。

问题分析：

• AllocFromPool 采用 first-fit 搜索连续块。归还时不合并，导致 pool 中出现大量小碎片。
• 例如池 [0,100) alloc(5) 后 [5,100)，release 后 [5,100)+[0,5)。再 alloc(5) 从 [5,100) 切，[0,5) 永远无法满足 num=5 的连续请求。
• 当前无显式 Release API（生命周期绑 insHandle），碎片化主要发生在 Acquire 失败回滚路径和 Reset 后。实际影响有限，但设计上应考虑合并。

建议修复： ReturnToPool 追加后对 pool 按 startId 排序并合并相邻块。若性能敏感，可惰性合并（仅当 AllocFromPool 找不到连续块时触发一次全量合并）。注意合并需在 mapMutex_ 保护下或 pool 所属 instance 的单线程上下文中执行。

[MEDIUM] ReturnToPool 简单追加可能导致长期碎片化

问题分析：

• 第 70 行 pool.emplace_back(info.startId, info.num); 直接将归还的 block 追加到 pool 末尾
• 没有对 pool 进行排序或合并相邻 block 的操作
• 长期运行后，pool 中可能累积大量碎片化的小块，降低 AllocFromPool 找到大块连续资源的效率
• 例如：释放 [5,3] 和 [8,2] 后，pool 中会有两个不连续的块，但实际上 [5,5] 是一个更大的连续块

建议修复： 在 ReturnToPool 后调用一个合并函数（可选优化），对 pool 排序并合并相邻 block。

注意：这是一个性能优化，不是 correctness 问题。是否需要合并取决于实际碎片化情况。

src/base_comm/resources/ccu/ccu_instance/ccu_var_event_res_mgr.cc:70

[LOW] CcuVarEventRes::devLogicId 为死字段

第 31 行：int32_t devLogicId{-1}; 在 AllocAndRecord 中被赋值 res.devLogicId = devLogicId_;，但全代码链路中（GetVariableXnId / GetEventCkeId / SaveAddrs / GetSavedAddr / UnmapSavedAddrs / ReleaseByHandle / ReleaseByInstance / ExcludeAllocatedFromRepo）均未读取该字段。

问题分析：

• 该字段可能是早期设计遗留或预期用于调试/日志，但当前所有日志均使用 CcuVarEventResMgr::devLogicId_（成员变量）而非 res.devLogicId。
• 死字段增加 struct 体积（4 字节加可能的 padding），在 resMap_ 中每个条目都携带，无实际用途。

建议修复： 若确无使用计划，删除 CcuVarEventRes::devLogicId 字段及其赋值。若保留用于调试，加注释说明用途并在至少一条日志中引用。