必须用args和*kwargs的场景是函数签名无法预知参数个数或类型时，如写装饰器、封装API、通用回调、可扩展初始化；二者须按序出现且不可颠倒。
什么时候必须用 *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）来守住关键字段：
立即学习“Python免费学习笔记（深入）”；
def send_email(*, to, subject, body="", cc=None):
...
这样 send_email("a@b.com", "hi") 就会立刻报错，强制调用方显式命名。
-
*args适合“追加可选内容”，不适合“模糊必填项” - 如果函数逻辑依赖某些参数一定存在，别靠
*args吞掉，用命名参数 +*分隔符约束 - 调试时打印
args和kwargs内容，常发现传参顺序错位——这是最隐蔽的 bug 来源之一
**kwargs 常见误用：盲目透传导致配置项失效
很多人写封装函数时习惯这么干：
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 生效（错误！）
这种写法在动态构造请求参数时很常见，但一旦顺序写反，关键配置就被静默覆盖。
- Python 3.9+ 支持
|合并字典：final_kwargs = defaults | user_opts，更明确、不可逆 - 用
dict(**defaults, **user_opts)也行，但要注意后者字段会覆盖前者 - 如果涉及嵌套结构（如
headers合并），**kwargs无法自动 merge，得手动处理
真正难的从来不是语法，而是搞清谁该控制什么参数、谁该负责校验、谁该承担默认行为——*args 和 **kwargs 只是工具，不是设计决策的替代品。
