跨系统集成中的联动数据丢失，往往不是文件损坏，而是中间格式在设计时没有给属性传递预留明确通道。一个带完整信息的模型从设计软件导出后，管理平台里只剩下几何轮廓，原先挂接的房间编号、系统分类、采购代码全部消失。源系统中的私有属性没有被映射到标准字段，导入端即便读取文件也无从恢复。要解决这类问题，需要从中间格式的字段设计入手，显式保留全局唯一标识和可扩展的属性映射区。
接下来从丢失定位、格式设计、导入实现和长期维护四个角度展开。
一、先定位属性是在哪一步丢失的
联动数据丢失最容易发生在转换阶段。许多导出器采用白名单机制，只输出标准规范中明确列出的字段。以BIM模型导出IFC为例，墙、门、设备的基础几何、空间位置、类型名称通常可以保留，而项目自定义的成本代码、运维负责人、采购批次等信息往往不在标准字段之内。转换器发现这些属性没有对应位置时，会直接忽略，而不是写进扩展区域。最终文件看似正常，下游系统却查不到关键的联动依据。
比属性缺失更隐蔽的是唯一标识不稳定。源系统可能使用数据库自增主键或会话级句柄作为构件ID，导出到中间格式后重新编号为1、2、3。第一次导入时还能对应，第二次导出只要顺序变化，下游系统就会把旧对象误认为新对象，或者把属性挂到错误对象上。没有稳定的全局唯一标识，属性传递就没有可靠的锚点。
另外，层级关系与引用关系也经常被中间格式抹平。设备从属于房间、阀门从属于管路、任务从属于合同，这些父子或引用关系在导出时被拍平成一张列表，但没有保留父节点标识。导入端重新建树时只能靠名称猜测，一旦名称重复或本地化翻译，联动关系就彻底断裂。
二、用全局ID和属性字典补上格式短板
解决联动丢失的核心不是把私有属性强行塞进标准字段，而是在中间格式中建立两个稳定区域：一是每个对象的全局唯一标识，二是可扩展的属性字典。全局ID建议使用UUID或GUID，并在源系统中持久化保存。每次导出时读取同一个ID，不允许临时生成。这样下游系统无论第几次导入，都能通过ID找到历史对象，实现更新而不是重复新建。
{
"schemaVersion": "1.0",
"globalId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
"type": "Door",
"name": "M-102",
"properties": [
{
"key": "FireRating",
"displayName": "防火等级",
"dataType": "string",
"value": "90min",
"unit": ""
},
{
"key": "CostCode",
"displayName": "成本代码",
"dataType": "string",
"value": "CC-2030",
"unit": ""
}
]
}
上述结构把属性从固定的已知字段中解放出来。导入端不需要预先知道每个业务字段的名称，只需要遍历属性数组，按key写入目标系统的自定义属性表。为了让不同团队理解同一字段，可以同时保留显示名、数据类型和单位。尤其是数据类型，缺少它时字符串和数值经常发生错误转换，例如把枚举值转成数字，导致比对失败。
如果中间格式是XML，同样可以通过明确的属性节点保留扩展信息。与标准节点不同，自定义属性放在独立的扩展命名空间下，避免和核心结构混在一起。下面是一个简化示例：
<ExchangeDocument version="1.0">
<Objects>
<Object globalId="f47ac10b-58cc-4372-a567-0e02b2c3d479" type="Door">
<Properties>
<Property key="FireRating" dataType="string" unit="">90min</Property>
<Property key="CostCode" dataType="string" unit="">CC-2030</Property>
</Properties>
</Object>
</Objects>
</ExchangeDocument>
XML方案的优点是层级关系直观，属性节点天然支持重复出现。导入端通过XPath或DOM遍历属性节点即可。无论选择JSON还是XML，关键是保证每个业务对象都有一个不变的标识，并且自定义属性明确写出键名、类型和值，而不是依赖隐式顺序。
三、导入端的属性传递与校验
中间格式再完整，如果导入端逻辑只读取固定字段，属性仍然会丢失。正确的做法是先解析全局ID并在目标系统中查找已有对象，然后遍历属性数组写入扩展字段。对于未匹配的对象，可以创建新记录，但必须保留源文件中的ID，不能重新生成。对于已存在的对象，则更新属性并记录变更。
function importObject(data) {
var existing = findObjectByGlobalId(data.globalId);
var target = existing || createObject(data.globalId, data.type);
if (data.properties) {
for (var i = 0; i < data.properties.length; i++) {
var p = data.properties[i];
target.setProperty(p.key, p.value, p.dataType);
}
}
return target;
}
这段逻辑虽然简单，但已经覆盖了属性传递的核心路径。需要注意的是，目标系统中的属性表应当允许动态扩展，不能只预留少数几个固定列。常见做法是使用键值对表，列包括对象ID、属性键、属性值、数据类型。这样即使后续新增业务字段，也不需要修改数据库结构。
导入后还应执行属性完整性校验。导出前统计源对象的属性数量，导入后按同一对象统计目标系统中的属性数量，如果数字不一致，立即输出差异报告。对于关键属性，可以计算值哈希并比对，防止值没有丢失但内容被截断或转换错误。校验失败时不要静默跳过，应写入日志并通知数据负责人。
四、长期维护时防止二次丢失
中间格式上线后，最大的风险来自版本升级和字段变更。团队在较新的格式版本中删除旧字段，或者修改字段含义，都会让已存档的中间文件在下一次读取时丢失信息。兼容策略是只增不改：新版本可以增加字段，但不要移除旧字段，对于废弃字段可以标记为deprecated，导入端仍然读取但不再使用。
属性映射关系最好集中维护，例如放在统一的配置文件中。文件可以保存源系统字段名、中间格式键名、目标系统字段名三者的对应关系。以Windows路径为例，映射文件可以放在 C:\exchange\mapping.json，由转换服务启动时统一加载。这样避免每个开发者各自写一套映射，导致同一个属性在不同项目中名称不一致。
如果业务允许，还应该建立回写机制。属性传递不只是单向导入，目标系统中的修改需要同步回源系统或下一条流程。通过全局ID和版本号标记变更，可以在下次同步时只处理差异部分，避免整表覆盖。稳定的ID加上可扩展的属性字典，配合映射配置和校验机制，联动数据丢失问题就能被控制在一个很小的范围内。