资产箱第一次导入能成功，再导入同一个包却出现关联异常。这类问题很容易被理解成“少了个去重”，但报表、属性和看板之间存在依赖，重复创建只是其中一部分。
同名不一定是同一个对象
属性不只有名字，还可能有父属性、所属对象和维表绑定。不同父对象下可以出现同名子属性；虚拟属性、普通属性和维度属性也不能只凭显示名混在一起比较。
跨项目之后，源 ID 更不能直接当作目标 ID。找到一个同名对象，仍然需要确认身份和兼容性，再建立目标引用。
计划阶段要区分三种结果
| 处理结果 | 当前资产 | 对下游的含义 |
|---|---|---|
| 新建 | 生成目标对象与 ID 映射 | 等待创建完成后再导入依赖它的对象 |
| 复用 | 绑定已确认的目标对象 | 下游仍可以继续，不需要重复创建上游 |
| 跳过 | 当前对象不可用或不导入 | 必需依赖它的下游也可能无法继续 |
如果把“复用”也放进失败传播队列，下游就会收到“依赖已跳过”，尽管目标项目明明已有可用对象。
修复需要同时看图和执行器
重复开箱相关提交调整了资产读取、冲突规划、缺失依赖检测、导入执行与引用解析。父子属性的依赖也需要补齐到图里，让导入顺序、冲突判断和失败传播使用同一套关系。
计划执行时按依赖顺序处理，引用解析再使用目标 ID。判断不能只停留在“表里有没有记录”，还要检查导入后报表配置、属性归属和维表关系是否真的指向正确对象。
后续列结构补齐又补上了另一层：元数据有定义，底层数据源也要具备对应列。配置迁移与实际可查询之间还有一段距离。
留下的检查点
- 用“同包再次导入”和“目标已有部分资产”验证复用路径。
- 用“同名但不同父属性”检查身份判断。
- 在计划里核对下游是否被错误传播跳过。
- 导入后检查目标引用与列结构，而不只统计新增记录数。
这里最有价值的经验是：一个局部去重规则，可能改变整张依赖图的可执行性。修复需要沿着规划、映射、落库和使用链路一起看。
记录对应 2026-09-09 的重复开箱修复 2e611ab7f，以及 2026-10-08 的列结构补齐 734509a1f。