修改Python AWS Lambda处理函数的默认签名是否属于最佳实践？

修改Lambda处理函数的默认签名（比如添加*args, **kwargs或默认参数）本身不算绝对的不良实践，但会带来一些潜在问题，需要结合场景权衡：

可能存在的问题 #

• 可读性与维护成本上升：官方标准签名def handler(event, context):是所有Lambda开发者的共识，自定义签名会让团队成员第一时间产生困惑——额外参数的用途是什么？谁会传入这些参数？如果没有清晰的注释，后续维护、新人接手都会增加理解成本。
• 隐藏的运行时错误风险：如果自定义签名时没有给额外参数设置默认值（比如写def handler(event, context, extra_arg):），Lambda运行时调用函数时会直接抛出参数不匹配的错误；就算用了*args, **kwargs，如果代码里不小心尝试读取这些未被传入的参数，也会触发IndexError或KeyError。
• 兼容性与扩展性隐患：虽然目前Lambda运行时只会传入event和context两个参数，但如果未来AWS调整调用逻辑（概率极低），自定义签名的兼容性会比标准签名差；另外，自定义签名可能会和一些Lambda工具（比如本地测试框架、监控工具）的预期不匹配，导致工具无法正常工作。
• 装饰器滥用风险：这种写法确实能适配装饰器的参数需求，但如果装饰器设计不严谨，会让处理函数的逻辑变得晦涩——比如装饰器注入的参数和业务逻辑耦合过紧，后续修改装饰器时可能影响到处理函数的正常运行。

合理使用的场景与注意事项 #

如果是为了依赖注入这类明确的需求（比如用装饰器注入数据库连接、配置项），自定义签名是可行的，但要注意：

• 给额外参数设置默认值，确保Lambda运行时直接调用不会出错，比如def handler(event, context, db_conn=None):
• 给函数添加清晰的注释，说明额外参数的用途、来源（比如来自哪个装饰器）
• 团队内部统一规范，避免随意修改签名，保持代码风格的一致性

内容的提问来源于stack exchange，提问作者Javier Novoa C.