我跟你讲，当有人问我“Python怎么决策”的时候，我脑子里冒出来的第一个念头就是——这个问题，可真不小。你要是以为答案就是if/elif/else三件套，那真的，太天真了。那只是冰山浮在水面上的一角，连十分之一都不到。真正的决策，是藏在水面之下的那座巨无霸。

行，咱们就从这个最基础的“三件套”说起吧。if-elif-else，每个学Python的人最先接触的逻辑控制，就像你学走路，总得先会站。比如，写个简单的判断，今天气温多少度，穿什么衣服。

“`python

这代码我就不写全了，你懂我意思

temperature = 15
if temperature > 25:
print(“穿短袖！浪起来！”)
elif temperature > 15:
print(“加件薄外套，别嘚瑟。”)
else:
print(“裹紧你的小棉袄！”)
“`

简单，直接，粗暴。对吧？处理两三种情况，没毛病。但如果，你的业务逻辑一上来，情况多得像夏天傍晚的蚊子，什么VIP等级1到VIP等级100，每个等级的折扣还不一样。你怎么办？写一百层elif？我的天，那代码写出来得有多丑？一长串看不到头的if-elif-else迷魂阵，半年后你自己回来维护，都得骂一句“这哪个憨憨写的？”。

所以，这会儿，Python决策的第一个进阶玩法就该登场了——字典派发 (Dictionary Dispatch)。

这玩意儿，简直是代码界的降维打击。它的核心思想是，把条件和对应的操作，用键值对（key-value）的形式存起来。要用的时候，直接去查表，而不是傻乎乎地一个一个去比对。

还是那个VIP等级的例子。用if写，是灾难片。用字典呢？

“`python
def get_vip_discount(level):
discounts = {
‘VIP1’: 0.98,
‘VIP2’: 0.95,
‘VIP3’: 0.9,
# … 往下写到VIP100
‘VIP100’: 0.5,
}
# get方法的好处是，找不到就返回默认值，不会报错
return discounts.get(level, 1.0) # 默认为不打折

用起来多清爽？

my_discount = get_vip_discount(‘VIP3’)
``
你琢磨琢磨，这两种写法的气质是不是完全不一样了？if`版本像个没头苍蝇，到处乱撞。字典版本呢，像个图书管理员，根据你的索引号，刷一下就把书给你了。代码瞬间清爽得像夏天的冰可乐，可读性和可维护性，直接拉满。

这还没完。

如果你的决策，不是简单地返回一个值，而是要执行一整套复杂的操作呢？比如说，你要做一个支付功能，用户可以选择用支付宝、微信支付或者信用卡。每种支付方式的流程，从调用API到处理回调，都不一样。

这时候，你用字典派发，value存的就不能只是个简单的值了，得是函数！

“`python
def handle_alipay():
print(“正在调用支付宝接口，请扫码…”)
# …一堆复杂的逻辑

def handle_wechat_pay():
print(“正在拉起微信支付，请输入密码…”)
# …另一堆复杂的逻辑

payment_handlers = {
‘alipay’: handle_alipay,
‘wechat_pay’: handle_wechat_pay,
}

def pay(method):
handler = payment_handlers.get(method)
if handler:
handler()
else:
print(“不支持该支付方式”)

决策就在这一瞬间完成

pay(‘alipay’)
“`
看到没？这就是Python的魅力所在，函数它就是个“一等公民”，可以像普通变量一样被传来传去。这种把不同的算法（处理逻辑）封装起来，让它们可以互相替换的玩法，在设计模式里，有个非常响亮的名字——策略模式 (Strategy Pattern)。

用字典和函数实现的，就是一个简易版的策略模式。你的主逻辑（pay函数）根本不关心具体怎么支付，它只负责根据“策略”（用户选择的支付方式）来调用对应的“处理器”（handle_alipay这些函数）。想增加一种新的支付方式？比如银联支付？简单！你只需要再写一个handle_union_pay函数，然后在字典里加个键值对就完事了。对原来的主逻辑，一！个！字！都！不！用！改！

这就是决策的艺术。把“决策”本身和“决策后要干的事”彻底分离开。

最后，我想聊一个更“Pythonic”的，更接近哲学层面的决策方式。它叫 EAFP (Easier to Ask for Forgiveness than Permission)，翻译过来就是“事后道歉比事前请示更容易”。

这跟我们之前习惯的 LBYL (Look Before You Leap)，“三思而后行”，是完全相反的思路。

啥意思？举个例子。你想读取一个字典里的某个key，LBYL的思路是：

“`python

LBYL: 先看（Look）再跳（Leap）

my_dict = {‘name’: ‘老王’}
if ‘age’ in my_dict:
age = my_dict[‘age’]
else:
age = 18 # 默认值
``
先用in判断一下‘age’`在不在，在，我再取值。很稳妥，对吧？像个小心翼翼的老太太。

但Python大神们更推崇EAFP的风格：

“`python

EAFP: 先干了再说，出了问题再补救

my_dict = {‘name’: ‘老王’}
try:
age = my_dict[‘age’] # 直接上手去拿
except KeyError: # 如果报错了（KeyError），说明没有
age = 18 # 这时候再给默认值
``
这种风格看起来有点鲁莽，上来就干，错了再说。但它在很多场景下，尤其是当你预期操作大概率会成功的时候，效率更高，代码也更直接。它把正常的业务逻辑放在try里面，一目了然，而把异常情况的处理丢到except`里。主次分明。

这种决策方式，体现了一种乐观主义精神：我默认你是对的，我先按对的来处理。这在处理文件、访问对象属性等很多地方，都是非常地道的Pythonic写法。

所以你看，Python怎么决策？

• 它可以是if语句那种最朴素的直来直去。
• 它可以是字典派发那种高效、优雅的查表。
• 它可以是策略模式那种高内聚、低耦合的架构之美。
• 它甚至可以是EAFP这种深入骨髓的、乐观的编程哲学。

选择用哪一种，本身就是程序员最高级的“决策”。它考验的，早已不是你对语法的熟练度，而是你对代码结构、对软件工程、乃至对问题本质的理解深度。

下次别再只想着if-else了，多想想背后那座巨大的冰山。那才是真正有意思的地方。