Python的and/or返回操作数本身而非布尔值，按短路逻辑求值：and遇falsy返左、否则返右；or遇truthy返左、否则返右；需警惕falsy合法值误触发副作用及优先级陷阱。
and 和 or 不是布尔函数，它们返回操作数本身
Python 的 and 和 or 从不强制转成 True 或 False。它们按顺序求值，遇到能决定整个表达式真假的值就停，然后直接返回那个值——可能是数字、字符串、None，甚至自定义对象。
比如 0 and "hello" 返回 0，不是 False；"" or [1, 2] 返回 [1, 2]，不是 True。这和 C/JS 里纯返回布尔值完全不同。
- 只要左边为 falsy（如
0、None、""、[]），and就立刻返回左边值，不再看右边 - 只要左边为 truthy，
or就立刻返回左边值，右边根本不会执行 - 如果
and左边是 truthy，它会继续求右边，并返回右边的原始值（不管真假） - 如果
or左边是 falsy，它会继续求右边，并返回右边的原始值
短路求值导致副作用只在需要时触发
因为右边操作数可能完全不被求值，所以带副作用的表达式（比如函数调用、IO、赋值）放右边时，行为是条件性的——这既是便利，也是坑源。
常见误用：data = get_user() or create_default() 看似简洁，但如果 get_user() 返回 0 或空列表（falsy 但合法），create_default() 就会被错误触发。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 适合场景：提供默认值（
config.get("timeout") or 30），但前提是你知道 key 对应的合法值不会是 falsy - 危险场景：用
or做“空值 fallback”，却忽略了业务中0、False、""是有效数据 - 更安全的写法是显式判断：
config.get("timeout") if config.get("timeout") is not None else 30，或用defaultdict/get(..., default)
and/or 链式写法容易读错优先级
and 优先级高于 or，但人眼容易当成左到右平级处理。比如 a or b and c 实际等价于 a or (b and c)，不是 (a or b) and c。
更隐蔽的是多层混合：x = a and b or c 看似“如果 a 则 b 否则 c”，但当 b 是 falsy 时，整个表达式会返回 c，逻辑就崩了——这不是三元运算符的替代品。
- 永远用括号明确意图：
(a and b) or c或a and (b or c) - 真要模拟三元，老实用
b if a else c：语义清晰、无歧义、不依赖真假值含义 - 链式
and（如a and b and c）安全，返回最后一个 truthy 值或第一个 falsy 值；链式or（如a or b or c）同理
自定义对象的 __bool__ 和 __len__ 影响短路结果
你写的类如果没定义 __bool__，Python 会退而求其次调 __len__；如果两者都没，实例默认为 truthy。这意味着短路行为可能和你预期不符。
比如一个空容器类只实现了 __len__ 返回 0，它在 if obj: 或 obj and x 中就会被当作 falsy；但如果你忘了实现 __len__，哪怕逻辑上“空”，它也会是 truthy。
- 调试时注意：用
bool(obj)查看实际真假值，别凭直觉猜 - 如果类代表“可空状态”，建议明确定义
__bool__，避免依赖__len__的隐式规则 - 重载
__bool__必须返回bool类型，返回1或"yes"会抛TypeError
短路本身没毛病，麻烦在于我们总想靠它“省代码”，结果把数据合法性、副作用时机、对象真假定义这些隐性契约全搅在一起。越想省事，越得盯紧每个操作数到底是什么值、会不会被跳过、有没有副作用。
