f-string性能更优，Python≥3.6时比str.format()快1.5–3倍，因编译期完成拼接且无运行时解析开销；但format()在模板复用、动态字段名、国际化和自定义Formatter等场景仍不可替代。
f-string 性能更好，只要 Python ≥ 3.6，它在绝大多数场景下都比 str.format() 快 1.5–3 倍，且无额外运行时开销。
f-string 在编译期完成拼接，format() 在运行时解析模板
f-string 不是函数调用，而是 Python 解释器在编译阶段就生成对应字节码（如 LOAD_FAST + BINARY_ADD），变量求值和字符串拼接直接嵌入执行流；
str.format() 每次调用都要走完整流程：解析模板字符串 → 构建参数元组/字典 → 调用 _vformat() 引擎 → 查变量 → 类型转换 → 替换占位符。
- 这意味着哪怕只插一个变量，format() 也至少多出两层函数调用和一次词法分析
- 实测 100 万次简单插值：f"hi {name}" 约 42ms，"hi {}".format(name) 约 108ms（CPython 3.12）
哪些场景下 format() 仍不可替代
f-string 虽快，但不是万能的：
- 需要预编译模板复用时：比如日志格式统一为 "user: {name}, action: {op}"，后续多次 tmpl.format(name=..., op=...) —— f-string 每次都得重写整个字符串
- 字段名动态决定：想根据变量 key 取字典值，f"{data[key]}" 可行，但 f"{data[{key}]}" 会语法错误；而 "{data[{key}]}".format(data=data, key=key) 可安全运行
- 国际化（i18n）：翻译后的模板可能调整占位符顺序（如中文把 {age} 放前、{name} 放后），硬编码在 f-string 里的顺序无法 runtime 切换
- 自定义 Formatter 子类控制格式逻辑（如千分位+单位自动补全），format() 可接管整个解析过程，f-string 不支持
f-string 容易踩的坑：不是所有表达式都能往里塞
- 字面量花括号必须双写：f"key: {{value}}" 才输出 key: {value}；单个 } 会报 ValueError: Single '}' encountered
- 海象运算符 := 不能跨 {} 边界共享状态：f"{(x := 1)} and {x}" 报错，必须写成 f"{(x := 1)} and {(x)}" 或拆成两行
- 表达式内禁止未转义的反斜杠：f"path: {os.path.join('a', 'b\c')}" 直接 SyntaxError，得写成 r"b\c" 或 "b/c"
- 调试时别滥用 f"{x=}"：它每次执行都会求值，若 x 是耗时属性或有副作用，会影响行为；生产环境日志应优先用 logging.debug("x=%s", x) 延迟格式化
真正容易被忽略的是：性能差距只在高频场景（如循环内拼接、中间件日志、模板批量渲染）才有实际意义；单次拼接用哪个都行，但习惯一旦养成，f-string 的可读性、安全性、调试便利性会持续带来收益。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
