写业务代码时，几乎每个项目都会遇到这样的逻辑：根据一个变量的不同取值，给另一个变量赋上不同的值。比如根据订单状态返回状态文案、根据用户等级返回折扣系数、根据错误码返回提示信息。很多开发者的第一反应就是 if else 一路堆下去，分支少的时候还好，一旦条件超过五六个，代码就开始膨胀，改一个分支要在长长的判断链里来回找位置。这篇文章就来聊聊，怎么用最少的 if 语句把这类多分支赋值逻辑写得干净利落。
为什么多分支赋值适合用映射表替代
首先要明确一个前提：不是所有 if 都应该被消灭。包含复杂业务判断、副作用、提前返回的分支逻辑，if 语句依然是最佳选择。真正适合被简化的，是那种纯粹做赋值的分支，每个分支内部只有一行赋值语句，没有其他逻辑。
这类代码有一个共同特征：判断条件是同一个变量的不同取值，分支之间互斥且平行。比如下面这段典型的 JavaScript 代码：
function getStatusText(status) {
let text = '';
if (status === 0) {
text = '待支付';
} else if (status === 1) {
text = '已支付';
} else if (status === 2) {
text = '已发货';
} else if (status === 3) {
text = '已完成';
} else {
text = '未知状态';
}
return text;
}二十多行代码，实际只表达了一件很简单的事：状态和文案之间的一一对应关系。这种对应关系本质上就是一张查询表，用对象字面量来表示再合适不过：
function getStatusText(status) {
const statusMap = {
0: '待支付',
1: '已支付',
2: '已发货',
3: '已完成'
};
return statusMap[status] ?? '未知状态';
}改造后代码量减半，而且新增一个状态只需要在对象里加一行，不用再担心 else 的位置、括号的配对。更关键的是，读代码的人一眼就能看出所有状态的对应关系，而不需要在 if else 链条里逐个比对。
不同语言中的映射表写法与兜底处理
映射表思路在各语言里都有对应实现。JavaScript 和 Python 用对象或字典最直接，Java 里可以用 Map 或者 switch 表达式，Go 里用 map 加逗号断言，思路完全一致。
Python 的写法非常简洁，字典取值配合 get 方法可以顺便处理默认值：
def get_discount(level):
discount_map = {
'normal': 1.0,
'silver': 0.95,
'gold': 0.9,
'platinum': 0.85,
}
return discount_map.get(level, 1.0)注意兜底值的处理。JavaScript 中如果用 statusMap[status] 取一个不存在的键，会得到 undefined，直接展示给用户就是一串英文。可以用空值合并运算符 ?? 处理，但要小心 || 和 ?? 的区别：如果映射的值可能是 0 或空字符串这种合法的假值，用 || 会错误地走到默认分支，?? 只在 null 和 undefined 时才取默认值，更安全。
Java 里传统写法是 HashMap 初始化时逐个 put，代码反而更啰嗦。从 Java 14 开始，switch 表达式是更好的选择，它天然支持多分支赋值且强制考虑所有情况：
String getText(int status) {
return switch (status) {
case 0 -> "待支付";
case 1 -> "已支付";
case 2 -> "已发货";
case 3 -> "已完成";
default -> "未知状态";
};
}这种写法虽然没有消灭分支关键字，但把赋值逻辑压缩成了每个分支一行表达式，编译器还能检查是否遗漏返回，比老式的 switch break 风格安全得多。Go 则可以借助从 map 取值时的双返回值判断键是否存在：
var statusMap = map[int]string{
0: "待支付",
1: "已支付",
2: "已发货",
}
func getText(status int) string {
if text, ok := statusMap[status]; ok {
return text
}
return "未知状态"
}可以看到这里只剩一个 if，而且它的职责是判断键是否存在，不是做分支赋值，语义完全不同。
进阶技巧：配置外置与函数级映射
当映射项越来越多，或者映射关系需要频繁调整（比如运营要经常改文案），可以把表从代码里抽出去。简单的做法是放到单独的配置对象甚至 JSON 文件、数据库表中，运行时加载。这样改文案不用动代码、不用重新发版，代码本身也退化成一行查表取值。
另一种情况是分支里不只是简单赋值，还带一点轻量计算。比如不同会员等级的折扣不是固定值，而是要根据价格算一下。这时可以把映射表的值从普通值换成函数：
const priceStrategies = {
normal: price => price,
silver: price => price * 0.95,
gold: price => price * 0.9,
platinum: price => price > 1000 ? price * 0.8 : price * 0.85
};
function calcPrice(level, price) {
const strategy = priceStrategies[level] ?? priceStrategies.normal;
return strategy(price);
}这种写法本质上是策略模式的最简形态。它保留了映射表的平行结构，又支持每个分支有各自的逻辑，比一长串 if else 灵活得多。判断什么时候该用值映射、什么时候该用函数映射，标准很简单：分支体只有一行赋值就用值，需要计算或多个步骤就升级为函数。
这些场景不要硬套映射表
映射表不是银弹，有几种情况硬套反而更糟。第一是条件不是对同一个变量做等值判断，而是范围判断，比如分数段位映射。对象字面量的键没法表达范围，虽然可以用数组配合 find 来做，但可读性未必比 if 好。第二是分支之间有依赖顺序，后面的分支要依赖前面分支的计算结果，这种流程型逻辑老老实实用 if 或提前返回更清晰。
第三是分支数量很少的情况。只有两三个分支时，三元表达式或简单的 if 完全够用，专门建一张映射表反而增加了间接层，读代码的人还要跳转到表定义处才能理解逻辑。经验值是：分支达到四个以上、且都是纯赋值时，映射表的收益才明显。
总结一下核心原则：if 语句适合表达流程和条件，映射表适合表达对应关系。写代码前先想清楚眼前的逻辑到底是哪一种，把对应关系从 if 分支中剥离出来，代码自然就简洁了。下次再看到自己写出五六层的 else if 赋值链，不妨停下来问一句：这会不会其实就是一张表？