f-string 比 format() 快因编译期拼接、无函数调用与解析开销；Python ≥3.6 应优先使用，仅延迟格式化等场景用 format()；字面量花括号需双写，混用位置/命名参数在 format() 中报错而 f-string 无此限制。
f-string 为什么比 format() 快
因为 f-string 在编译期就完成字符串拼接，而 format() 是运行时调用方法、解析占位符、再做替换。Python 解释器对 f-string 做了专门优化，没函数调用开销，也没格式化字符串的解析过程。
实操建议：
- 只要 Python 版本 ≥ 3.6，优先用 f-string，尤其是循环内、高频日志、模板渲染等场景
-
format()在需要延迟格式化（比如把模板字符串存起来，稍后才填值）时仍有价值 - 注意：f-string 中的表达式会在每次执行时求值，不能“缓存”逻辑；
format()的参数可复用，适合多次填同一组变量
f-string 里怎么写带花括号的字面量
常见错误现象：f"key: {key} value: {{value}}" 报 ValueError: Single '}' encountered in format string —— 因为未转义的 } 会被误认为格式化结束符。
正确做法是用两个大括号表示一个字面量 { 或 }：
立即学习“Python免费学习笔记（深入）”；
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 想输出
{hello}，写成f"{{{hello}}}"（注意：外层一对，内容里再套一对） - 纯字面量
{就写"{{"，}就写"}}"，和format()规则一致 - 别试图用反斜杠转义，
\{在 f-string 中无效
format() 的位置参数和命名参数混用会怎样
会直接报错：ValueError: cannot switch from automatic field numbering to manual field specification。
这是 format() 的硬性限制，不是 bug：
- 全用位置（
"{} {}".format(a, b)）✅ - 全用名字（
"{x} {y}".format(x=a, y=b)）✅ - 混用（
"{} {y}".format(a, y=b)）❌ 立刻失败 - f-string 没这问题：
f"{a} {b}"和f"{a} {b}"本质都是表达式，无所谓“编号”或“命名”
format() 的格式说明符在 f-string 里怎么写
写法几乎一样，只是挪到花括号里——但容易漏掉冒号前的空格或搞错嵌套顺序。
示例对比：
-
"{:.2f}".format(3.14159)→f"{3.14159:.2f}" -
"{name:>10}".format(name="foo")→f"{name:>10}" - 复杂点的：
"{val!r: → <code>f"{val!r:（注意 <code>!要紧贴表达式，不能写成f"{val !r:...}"） - f-string 不支持
format()的某些老式语法，比如%风格（"%.2f" % x），也不能用format()的自定义__format__方法以外的全局注册格式器
真正容易被忽略的是 f-string 的调试模式：在表达式末尾加个等号，比如 f"{x=}" 会输出 x=42，这个语法既简洁又安全，但很多人写完 f"{x}" 还手动拼 "x="，多打字还易错。
