关键字参数提升可读性与维护性，明确参数意图，降低理解成本，适合多参数或易混淆场景，且性能影响可忽略。
关键字参数让函数调用意图一目了然
函数调用时传一堆位置参数，过三个月自己都看不懂 do_something(True, 5, None, "utf-8") 里每个值到底对应什么。关键字参数直接把“谁是谁”写进调用里，比如 do_something(validate=True, timeout=5, encoding="utf-8")，不用翻文档也能猜个八九不离十。
这不是为了“好看”，而是降低维护成本：别人改你代码、你回来看自己半年前的调用，都能少一次查源码的步骤。
- 适合参数多于 3 个，或类型/含义容易混淆的场景（比如
datetime.datetime(2024, 1, 1, 12, 0, 0)不如datetime.datetime(year=2024, month=1, day=1, hour=12)） - 布尔标志位尤其推荐用关键字——
load_config(force=True)比load_config(True)明确十倍 - 别为了“统一风格”强行给所有参数加关键字，单参数函数如
len(my_list)或str(42)加了反而啰嗦
混合使用位置参数和关键字参数的边界在哪
Python 要求位置参数必须在关键字参数之前，否则报错 SyntaxError: positional argument follows keyword argument。这不是限制，是强制你保持调用逻辑清晰：固定顺序的部分放前面，可选/易变的部分放后面用关键字标出。
常见错误是写成 requests.get(url="https://api.com", "json") —— 这会直接语法报错；正确写法是 requests.get("https://api.com", json=True) 或全用关键字 requests.get(url="https://api.com", json=True)。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 位置参数用于必填且顺序稳定的核心输入（如文件路径、URL、主数据）
- 关键字参数用于可选配置、标志、回调等辅助性参数
- 一旦用了关键字参数，它后面的参数也必须用关键字（除非函数定义允许位置参数继续）
带默认值的参数必须声明为关键字参数吗
不是必须，但强烈建议。函数定义里写 def save_data(path, format="json", compress=False):，调用时仍可用位置方式 save_data("out.txt", "yaml")，但这时 "yaml" 是赋给 format 还是 compress？靠记忆或查定义，容易错。
更稳妥的做法是把带默认值的参数全部放到参数列表末尾，并在调用时显式使用关键字：save_data("out.txt", format="yaml", compress=True)。这样即使未来函数增加新参数，也不会破坏旧调用的语义。
- 默认值参数放在非默认参数之后，这是 Python 语法强制要求
- 如果某个默认值参数经常被跳过（比如只改最后一个），就更要依赖关键字，避免传一堆
None占位 - 用
*args和**kwargs时，关键字参数能自然落到**kwargs里，位置参数则必须严格对齐形参顺序
关键字参数影响性能吗？值得为可读性牺牲速度吗
几乎不影响。CPython 解释器对关键字参数的解析开销极小，日常业务代码里测不出差别。只有在每秒调用数百万次的底层循环里才可能有微秒级差异，而那种场景早该换 C 扩展或 Cython 了。
真正拖慢开发的是理解成本：花 2 分钟看懂一个调用，比快 0.001ms 更重要。可读性不是“锦上添花”，是防止自己和同事掉坑里的安全带。
- 不要因为“听说关键字慢”就回避它——没实测就信这种说法，比用关键字本身风险更大
- 如果真遇到性能瓶颈，先用
cProfile定位热点，而不是预设“关键字=慢” - IDE 和类型检查器（如 mypy）对关键字参数的支持更好，能提前发现拼写错误，比如把
encodng="utf-8"这种 typo 拦在运行前
最常被忽略的一点：关键字参数名要和变量名、文档字符串保持一致。写成 write_file(path="/tmp/log", fmt="json")，但函数定义是 def write_file(path, format=...)，这时候 fmt 就成了隐式约定，下次有人加参数或改名，就悄悄埋下 bug。
