仅位置参数（/）不提升纯Python函数性能，其价值在于强化接口契约、辅助静态检查、简化C扩展参数解析，并为JIT/Cython优化提供前提；真正提速需依赖底层编译或缓存。
Python 3.8 引入的 posonlyargs（仅位置参数）语法本身不加速函数调用，但能帮你写出更明确、更不易误用的接口——真正的“加速”来自后续的 C 扩展或 JIT 优化场景中对参数绑定的简化。
为什么 def f(a, /, b) 不会提升纯 Python 函数性能
CPython 解释器对普通函数调用的参数解析逻辑在位置参数和关键字参数混合时才稍有开销；而一旦全部用位置参数（包括 / 左侧），解释器仍需构建 PyFrameObject、填充 locals 字典、处理默认值等。实测显示，timeit 下 f(1, 2) 和 f(1, b=2) 的差异通常在纳秒级，无实际意义。
真正受益的是：
- 静态类型检查器（如 mypy）能更早捕获
f(a=1, b=2)这类非法调用 - API 设计者可锁定参数名变更空间（比如未来把
b改成value不影响老调用） - C 扩展函数（如 NumPy 或 pandas 内部）利用
PyArg_ParseTuple直接按位置取值，跳过 keyword dict 查找
哪些场景下位置参数能带来可观收益
典型例子是高频数值计算函数，尤其是被 Cython 或 PyO3 封装的底层函数。例如你封装一个向量加法：
立即学习“Python免费学习笔记（深入）”；
def vec_add(a, b, /, out=None):
# 实际调用 cdef 函数，/ 确保 a/b 必须传位置，避免 Python 层 keyword 解析
return _vec_add_impl(a, b, out)
这时 / 的作用不是提速 Python 层，而是让 C 层实现可以安全假设前两个参数一定存在且顺序固定，省去 PyDict_GetItemString(kwargs, "a") 这类操作。
常见适用场景：
- NumPy 风格函数（如
np.array(object, dtype, /, *, copy=True)） - 需要与 C/Fortran 库对接的包装函数
- 被
@njit（Numba）或@cython.boundscheck(False)装饰的数学函数
容易踩的坑：混淆“语法强制”和“运行时优化”
写 def f(x, y, /) 后仍可能慢，如果你在函数体内做这些事：
- 反复访问
locals()或用**kwargs中转参数 - 在循环里调用该函数但没做
__builtins__.__dict__.update(...)类似的全局缓存（极少需要） - 误以为加了
/就能绕过 Python 的参数校验 —— 实际上错误调用（如f(x=1, y=2)）会在进入函数前就抛TypeError，反而多一次检查
另一个隐蔽问题：某些 IDE 或文档生成工具（如 Sphinx autodoc）对 / 语法支持不全，可能导致签名显示异常或类型提示丢失。
替代方案比硬加 / 更有效
如果目标确实是提速函数调用，优先考虑：
- 用
functools.lru_cache缓存结果（适合纯函数+重复输入） - 将热路径函数用
cython编译，此时参数声明写成def func(double[:] a, double[:] b)比 Python 层加/有效得多 - 用
__slots__ = ()减少实例属性查找开销（对方法调用间接有益） - 避免在循环内创建闭包或嵌套函数——这比参数传递开销大几个数量级
位置参数语法是接口契约工具，不是性能开关。它最有价值的地方，在于让调用方和实现方都清楚“什么不该变”，而不是“现在快了多少”。
