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 —— 因为未转义的 } 会被误认为格式化结束符。
正确做法是用两个大括号表示一个字面量 { 或 }:
- 想输出
{hello},写成f"{{{hello}}}"(注意:外层一对,内容里再套一对) - 纯字面量
{就写"{{",}就写"}}",和format()规则一致 - 别试图用反斜杠转义,
\{在 f-string 中无效
format() 的位置参数和命名参数混用会怎样
会直接报错:ValueError: cannot switch from automatic field numbering to manual field specification。
图片提示词生成器?不止如此。 马甲系统 —— 把脑海中的画面,翻译成AI能理解的专业表达。 用得越多,它越懂你:首次需要多问几句确认方向,用久了几乎一说就懂。 用得越多,它越快:缓存机制让后续对话越来越省。 RAG进化:成功案例持续入库,越跑越聪明。 输入「新手指南」查看完整功能介绍
这是 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=",多打字还易错。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!










