映射规则基础：从简单到复杂的五种模式

数据映射这件事，说白了就是「把A字段的值变成B字段的值」。听起来简单吧？但我在项目中见过太多人栽在基础规则上。今天咱们就把五种最核心的映射规则掰开揉碎讲清楚。

一对一映射是最简单的模式。源字段和目标字段之间，就是「你变我变」的关系。

核心定义：源数据中的一个值，直接对应目标数据中的一个值。

举个例子，假设有个系统里性别字段存的是「M/F」，但新系统要的是「男/女」。这就是典型的一对一映射。

// 一对一映射示例
{
  "M": "男",
  "F": "女"
}

我个人习惯把这种映射写成配置文件，而不是硬编码在代码里。为什么？因为业务方改需求的时候，你改个配置文件比改代码快多了。

我的经验：一对一映射虽然简单，但要注意源字段的枚举值是否完整。我曾经遇到过源系统突然多了一个「U」值（未知），结果映射直接报错。所以记得加个兜底逻辑。

一对多映射，就是一个源字段的值，要拆分成多个目标字段。这在实际项目中太常见了。

你想想看，很多老系统喜欢把「姓名」存成一个字段，但新系统要求「姓」和「名」分开。这就是一对多。

// 一对多映射：全名 -> 姓 + 名
"张三丰" -> {
  "lastName": "张",
  "firstName": "三丰"
}

嗯，这里要注意。一对多映射往往需要写转换逻辑，不能简单用配置搞定。我建议把这种逻辑封装成独立的转换函数，方便单元测试。

避坑指南：我曾经在处理地址字段时，以为「北京市海淀区中关村大街1号」可以简单按空格拆分。结果遇到「北京市东城区王府井大街」这种没有空格的地址，直接翻车。所以一对多映射一定要考虑边界情况。

多对一映射正好反过来。多个源字段要合并成一个目标字段。

比如，系统A存「省」和「市」两个字段，系统B只要一个「省份+城市」的完整地址。这就是多对一。

// 多对一映射：省 + 市 -> 完整地址
{
  "province": "广东",
  "city": "深圳"
} -> "广东省深圳市"

多对一映射有个坑：空值处理。如果某个源字段是空的，合并结果该怎么处理？我个人习惯是：如果任何一个源字段为空，整个目标字段也置空，并记录日志。

核心原则：多对一映射的优先级规则要提前定好。比如「主地址优先于备用地址」，这些规则必须在映射文档里写清楚。

条件映射，说白了就是「如果...那么...」。这是最灵活，也最容易出错的映射规则。

举个例子，根据用户的年龄范围，映射到不同的用户等级。

// 条件映射示例
if (age < 18) {
  level = "青少年"
} else if (age < 60) {
  level = "成年"
} else {
  level = "老年"
}

条件映射的难点在于条件的覆盖度。我见过一个项目，条件映射写了20多个if-else，结果漏掉了一个边界值，导致线上数据异常。

我的建议：条件映射一定要用决策表来管理。把条件和结果列成表格，逐行检查是否覆盖了所有可能的情况。别偷懒，这个步骤省不了。

默认值映射，就是当源字段没有值，或者映射规则找不到对应关系时，给目标字段一个兜底的值。

这听起来简单，但实际用起来门道很多。

// 默认值映射示例
{
  "sourceField": "gender",
  "mapping": {
    "M": "男",
    "F": "女"
  },
  "defaultValue": "未知"
}

默认值的选择很有讲究。我见过有人把默认值设成「0」或者「空字符串」，结果下游系统直接报错。默认值一定要和目标字段的数据类型兼容。

避坑指南：我曾经在一个金融项目中，把默认值设成了「-1」。结果下游系统把-1当成了有效值，直接参与计算，导致报表数据全错了。从那以后，我坚持默认值必须用业务上不可能出现的值，比如「N/A」或者「UNKNOWN」。

实际项目中，这五种规则很少单独使用。往往是组合在一起，形成复杂的映射链路。

你看，一个简单的用户等级映射，就用了三种规则。所以我说，映射规则不是孤立的知识点，而是需要灵活组合的技能。

总结一下：

这五种规则，是数据映射的基石。你想想看，不管多复杂的映射场景，拆解到最后，无非就是这五种规则的组合。把基础打牢了，后面学高级映射才会顺手。

下一章，咱们聊聊映射规则的优先级和冲突处理。那个更有意思，因为实际项目中，规则之间打架是常有的事。