Python 中不存在内联函数机制，def 和 lambda 均不触发内联优化；lambda 仅为单表达式语法糖，调用开销与 def 相同；性能瓶颈多源于解释器循环、对象创建等，而非函数调用本身。
内联函数在 Python 中并不存在
Python 没有编译期函数内联机制，def 定义的函数不会被自动展开为内联代码。所谓“内联函数”通常是开发者误用术语，实际指代的是 lambda 表达式、嵌套函数或手动复制逻辑的写法。CPython 解释器不会对任何用户定义函数做内联优化，这是语言设计决定的——Python 的动态特性（如运行时重绑定 func.__code__、猴子补丁）让静态内联不可行。
lambda 不等于内联，只是语法糖
lambda 仅提供一种简洁定义单表达式函数的方式，它仍生成真正的函数对象，调用开销与普通 def 函数一致。性能上没有优势，反而因无法使用语句、缺少文档字符串和调试信息，可能增加维护成本。
- 错误认知：
lambda x: x * 2比def double(x): return x * 2更快 —— 实测两者字节码几乎相同，调用开销无差别 - 真实瓶颈：函数调用本身在 Python 中开销较低，真正拖慢速度的是解释器循环、对象创建、属性查找（如
obj.method）等 - 适用场景：
lambda适合传给map()、sorted(key=...)等高阶函数作一次性回调，而非追求性能
想减少函数调用开销？优先考虑这几种做法
当 profiling 确认函数调用是热点（例如循环内高频调用小函数），可尝试以下替代方案，但需实测验证：
- 把小逻辑直接写进循环体，避免
def或lambda调用 —— 注意可读性下降，且无法复用 - 用局部变量缓存方法绑定：
method = obj.method; for x in xs: method(x)，省去每次点号查找 - 对数值计算密集场景，改用
numpy向量化操作，比任何 Python 层面的“内联”都有效得多 - 极端情况可考虑
cython或numba编译关键函数，它们能在 C 层实现真正内联
容易被忽略的兼容性陷阱
有人试图用装饰器或 AST 重写模拟内联，这类方案风险极高：
立即学习“Python免费学习笔记（深入）”；
- 修改
__code__或动态生成函数会破坏调试器断点、inspect工具和覆盖率统计 - 依赖闭包变量的
lambda或嵌套函数，若强行展开，可能意外捕获错误的作用域值 - PyPy 等替代解释器对代码生成行为更敏感，自定义内联逻辑很可能失效甚至崩溃
真正影响性能的从来不是“是否内联”，而是数据结构选择、算法复杂度、I/O 阻塞或 GIL 争用。别在函数调用上过早优化。
