Python函数调用为何支持解包含非标识符字符串键的dict

这个表现是Python刻意设计的行为，不是bug，核心逻辑可以从**kwargs的本质来理解：

• 函数的显式命名参数和**kwargs的校验规则本来就不一样：定义在函数参数列表里的显式参数，调用时传入的键必须是合法标识符，因为这些参数要直接绑定成函数作用域内的变量，而Python变量名本身就要求符合标识符规范，这部分校验是严格的。
• 但**kwargs的本质是「收集所有额外传入的关键字参数，组装成一个普通字典」，Python字典的键从来没有「必须是合法标识符」的要求。Python在解包传参时只做最基础的校验：键必须是字符串类型（所以整数键会直接报错），不会额外校验字符串是否符合标识符规则——毕竟这些键最终只是字典里的键值对，不需要绑定成独立的变量名。
• 之所以不做额外的标识符校验，是因为这种限制属于过度约束，反而会破坏大量通用场景的参数透传能力。Python的设计思路是把校验权交给开发者：如果你写的函数确实要求kwargs里的键都得是合法标识符、要拿来当变量用，自己在函数内部加校验就行，语言层面不做无意义的全局限制。

常见实际应用场景 #

• Web开发中的请求参数处理：写接口中间件、装饰器、通用请求处理函数时，经常要处理HTTP头、URL查询参数、表单字段，这些字段名很多本来就不是合法标识符：比如HTTP头的Content-Type带横杠、查询参数可能是数字开头、甚至业务自定义的带特殊符号的字段。这些参数收集到kwargs里之后，本来就是按字典键的方式读取，根本不需要绑定成独立变量，允许非标识符键传参的话，就可以直接把框架拿到的请求参数字典原封不动解包传入，不需要额外做键名替换。
  示例代码：

  def log_request_info(**kwargs):
      # 直接读取带横杠、数字开头的键，不需要提前转换
      print(f"请求内容类型: {kwargs.get('Content-Type')}")
      print(f"链路追踪ID: {kwargs.get('X-Trace-Id')}")
      print(f"自定义标记: {kwargs.get('123mark')}")
  
  # 直接把从Web框架拿到的请求头字典解包传入，无需修改键名
  request_headers = {
      'Content-Type': 'application/json',
      'X-Trace-Id': 'tkn_20240501_abc',
      '123mark': 'test_env'
  }
  log_request_info(**request_headers)
  

• 通用数据/配置处理：从JSON、YAML、CSV等外部数据源加载数据、读取配置文件时，拿到的字典键经常包含空格、横杠、数字开头的情况。写通用的数据清洗、配置校验函数时，这些键本来就是作为字典键操作，不需要绑定成变量，允许非标识符键传参就可以直接把加载到的字典解包传入处理函数，省掉大量无意义的键名转换工作。
• 通用代理、装饰器的参数透传：写日志装饰器、性能统计装饰器、RPC调用代理这类通用逻辑的时候，代码本身不需要关心下游函数接收的参数是什么格式，只需要把调用方传入的所有参数原封不动收集起来，再透传给下游实际执行的函数即可。如果语言层面强制拦截非标识符的字符串键，这种通用透传逻辑就会直接报错，根本无法兼容所有合法的调用场景。

关于「这个特性会掩盖问题」的顾虑，其实只存在于开发者需要把kwargs里的键作为独立变量使用的场景——但这种场景下开发者本来就需要做参数校验：比如你要从kwargs里取user_id参数，本来就要处理键不存在、键名错误的异常，和是否允许非标识符键没有关系。如果你的业务逻辑确实要求传入的键都是合法标识符，在函数内部加几行键名校验的成本极低，没必要让语言层面为了这个特定场景，给所有通用透传场景增加不必要的限制。

内容的提问来源于stack exchange，提问作者thorwhalen