Python *args 和 **kwargs 的真实用途-Python教程-PHP中文网

必须用args和*kwargs的场景是函数签名无法预知参数个数或类型时，如写装饰器、封装API、通用回调、可扩展初始化；二者须按序出现且不可颠倒。

python *args 和 **kwargs 的真实用途

什么时候必须用 `*args` 和 `**kwargs`

不是为了“看起来高级”，而是当函数签名无法提前确定参数个数或类型时，才真正需要它们。典型场景包括：写装饰器、封装第三方 API 调用、实现通用回调函数、构建可扩展的类初始化逻辑。

比如你写一个日志装饰器，要兼容所有被装饰函数的参数形式——它可能有 2 个位置参数，也可能有 5 个关键字参数，甚至混合使用。这时候硬编码 def wrapper(a, b, c=None) 必然失败，而 *args 和 **kwargs 是唯一能兜住所有情况的方式。

*args 接收任意数量的位置参数，打包成 tuple；**kwargs 接收任意数量的关键字参数，打包成 dict
二者必须按顺序出现：def func(a, b, *args, **kwargs)，不能颠倒，也不能插在必选参数中间
如果只传了关键字参数但函数没声明 **kwargs，会直接报 TypeError: func() got an unexpected keyword argument

`*args` 不是万能的“多参数兜底”，它会吃掉本该报错的调用

假设你定义 def send_email(to, subject, *args)，本意是让 to 和 subject 强制存在，其余可选。但调用 send_email("a@b.com") 不会报错——subject 会被当成第一个 *args 元素，to 反而成了 subject，逻辑全乱。

更安全的做法是用仅限关键字参数（keyword-only）来守住关键字段：

def send_email(*, to, subject, body="", cc=None):
    ...

这样 send_email("a@b.com", "hi") 就会立刻报错，强制调用方显式命名。

*args 适合“追加可选内容”，不适合“模糊必填项”
如果函数逻辑依赖某些参数一定存在，别靠 *args 吞掉，用命名参数 + * 分隔符约束
调试时打印 args 和 kwargs 内容，常发现传参顺序错位——这是最隐蔽的 bug 来源之一

`**kwargs` 常见误用：盲目透传导致配置项失效

很多人写封装函数时习惯这么干：

图片转Word

将扫描图像、截图或表单、文档及以文字为主的图片内容，转换为可编辑的 Word（.docx）文件。当用户提供包含文本内容的图片，并要求将其转为 Word 文档时，应使用此技能；或用户表达类似“把图片搞成 word 文字版”、“convert image to docx”、“extract text from image to Word”等需求时，也应调用此技能。

下载

def safe_request(url, **kwargs):
    return requests.get(url, **kwargs)

表面看没问题，但 requests.get() 本身接受 timeout、headers、verify 等几十个参数，而你的 safe_request 没做任何校验或默认值处理。结果可能是：用户传了 timeout=0.1 却没意识到这会让请求极易失败；或传了 verify=False 绕过证书验证却没留日志。

透传 **kwargs 前，至少应过滤、记录或转换关键参数（如把 retries 映射到内部 Session 配置）
不要让 **kwargs 成为“逃避设计”的借口——哪些参数该暴露？哪些该封装？得想清楚
如果函数只接受特定几个关键字参数，直接列出来比用 **kwargs 更清晰、更易维护

组合使用时容易忽略的细节：解包顺序和覆盖逻辑

当你同时解包多个参数来源时，顺序决定覆盖结果。例如：

defaults = {"timeout": 5, "verify": True}
user_opts = {"timeout": 0.5}
requests.get(url, **defaults, **user_opts)  # timeout=0.5 生效
requests.get(url, **user_opts, **defaults)  # timeout=5 生效（错误！）

这种写法在动态构造请求参数时很常见，但一旦顺序写反，关键配置就被静默覆盖。