三位选手登场：先认识一下它们
在进入测试之前，有必要先回顾一下这三种方式的基本形态。
百分号格式化（%） 是Python最古老的字符串格式化方式，继承自C语言的sprintf风格。它使用百分号作为占位符，后跟类型标识，例如%s代表字符串、%d代表整数。语法简洁，但灵活性有限，当需要同时处理多个变量时，容易出现"括号套括号"的嵌套噩梦。
str.format()方法 在Python 2.6时代登场，是对百分号格式化的一次重大升级。它使用花括号作为占位符，支持位置参数、关键字参数、属性访问甚至方法调用。语法更加清晰，可读性也有了质的飞跃，一度成为社区推荐的主流写法。
f-string 于Python 3.6横空出世，全称为Formatted String Literal。它在字符串前加一个f前缀，花括号内直接书写变量名或表达式，在运行时被实时求值并替换。它的出现几乎是降维打击——语法最简洁，执行最高效，一经推出便迅速席卷了整个Python社区。
基准测试设计：如何保证公平
在讨论性能之前，我们必须先明确测试方法论。一次有说服力的基准测试，需要控制变量、排除干扰。
我们的测试环境基于Python 3.11，使用timeit模块进行多次迭代取均值，确保结果具有统计意义。测试场景覆盖四种典型用法：简单变量替换、多变量拼接、带类型转换的格式化、以及涉及表达式求值的复杂场景。每种场景各执行一百万次，取平均耗时。
特别需要说明的是，我们刻意排除了字符串拼接（+号）这种方式，因为它在处理多变量时会产生大量中间对象，性能表现不在同一维度上，对比意义不大。
第一回合：简单变量替换
这是最基础、最高频的使用场景：将一两个变量的值嵌入到一段固定文本中。
测试结果令人一目了然：f-string以绝对优势领跑，平均耗时仅为百分号格式化的约六成，比str.format()更是快了接近百分之三十。百分号格式化在这个场景下表现最为迟缓，str.format()居中。
为什么差距如此悬殊？原因在于底层实现机制。f-string在语法解析阶段就完成了所有工作——它本质上是一种编译期优化，Python解释器在解析字节码时就已经知道了所有占位符的位置和类型，运行时只需做简单的值替换。而str.format()需要在运行时解析格式字符串、构建参数元组、执行方法调用，这一系列操作都会产生额外开销。百分号格式化虽然比str.format()略快一点点，但依然需要运行时解析，无法与f-string的编译期优势相提并论。
第二回合：多变量拼接
当需要替换的变量数量增加到五个甚至十个时，情况会如何变化？
结果显示，三者的性能排序没有改变，但差距进一步拉大。f-string依然是最快的，而且随着变量数量增加，它的优势更加明显。str.format()的耗时几乎呈线性增长，而百分号格式化的增长曲线更加陡峭。
这是因为str.format()在处理多个参数时，需要构建一个完整的参数字典或元组，然后逐个匹配占位符，这个匹配过程本身就有不小的成本。百分号格式化同样需要构建元组并逐位替换，而且它不支持关键字参数，变量顺序必须严格对应，这在多变量场景下容易出错，间接增加了调试成本。
f-string则完全没有这个问题——每个花括号都是独立求值的，互不干扰，解释器可以高度优化每个占位符的处理逻辑。
第三回合：带类型转换的格式化
这个场景模拟的是需要对变量进行格式化控制的情况，比如将浮点数保留两位小数、将整数补零对齐等。
在这个回合中，f-string依然保持领先，但优势有所收窄。原因是类型转换本身就是一项有成本的操作，无论哪种方式都需要执行相应的转换逻辑。不过，f-string在表达式求值方面的优势依然存在——你可以直接在花括号里写表达式，比如对一个变量做运算后再格式化，这在str.format()中需要借助额外的语法技巧才能实现。
百分号格式化在这个场景下依然垫底，而且它的类型控制语法相对笨拙，需要记忆一套格式说明符，使用体验并不友好。
第四回合：表达式求值与方法调用
这是最能体现三者设计哲学差异的场景。比如，你需要在格式化时调用一个对象的方法，或者对变量进行运算。
str.format()在这里展现出了它的灵活性——你可以在花括号内写完整的表达式，甚至调用方法。但这种灵活性是有代价的：运行时需要解析表达式、执行求值，性能损耗不可忽视。
f-string同样支持花括号内的任意表达式，而且由于它的求值发生在编译期已知的上下文中，解释器可以做更积极的优化。测试数据表明，在表达式求值场景下，f-string比str.format()快了约百分之四十到五十。
百分号格式化在这个场景下几乎无法胜任——它不支持在占位符中嵌入表达式，你必须提前计算好所有值，然后再传入。这不仅增加了代码冗余，也让整个流程变得繁琐。
综合排名与深层原因
经过四轮测试，最终的性能排名如下：
第一名：f-string —— 全面领先，在所有场景下都是最快的选择。
第二名：百分号格式化（%） —— 意外地排在中间，比很多人预期的要好，尤其在简单场景下与str.format()差距不大。
第三名：str.format() —— 表现最慢，但可读性最好，功能最全。
为什么f-string能做到如此出色？核心原因有三个：
第一，编译期优化。f-string的格式化字符串在字节码编译阶段就被解析完毕，运行时不需要再做任何字符串分析工作，这是它领先的根本原因。
第二，零额外对象创建。f-string在构建最终字符串时，不需要像str.format()那样创建临时的参数元组或字典，也不需要像百分号格式化那样构建格式化指令对象，内存开销极小。
第三，局部性优化。Python解释器对f-string有专门的优化路径，在CPython的源码中，f-string的处理被封装为独立的操作码，执行效率远高于通用的方法调用。
但性能不是唯一的标尺
虽然f-string在性能上全面胜出，但这并不意味着其他两种方式就该被抛弃。在实际工程中，选择哪种方式还需要考虑其他维度。
可读性与可维护性 是str.format()最大的优势。当格式化字符串很长、变量很多时，f-string会让代码行变得极长，影响阅读。而str.format()可以将格式模板与变量分离，结构更加清晰。在需要国际化或动态替换格式模板的场景下（比如从配置文件读取格式字符串），str.format()甚至百分号格式化反而是更合适的选择，因为f-string的格式必须在编写时确定，无法运行时动态替换。
向后兼容性 也是一个现实因素。f-string需要Python 3.6及以上版本，如果你的项目还运行在更早的版本上，那就只能在str.format()和百分号格式化之间做选择。在这种情况下，推荐使用str.format()，它的功能更全、语法更现代。
团队规范 同样不可忽视。有些团队出于代码风格统一的考虑，会明确规定使用某一种方式。在这种场景下，遵循团队规范比追求微小的性能差异更有价值。
实战建议：什么时候用什么
基于以上测试结论和工程考量，给出如下建议：
日常开发中，优先使用f-string。 它最快、最简洁、最符合Pythonic的风格。在百分之九十的场景下，它都是最佳选择。
需要动态格式模板时，使用str.format()。 比如从数据库或配置文件中读取格式字符串，再用变量填充，这种场景下f-string无法胜任。
维护遗留代码时，尊重原有风格。 如果项目中大量使用了百分号格式化，没有必要为了性能而全部改写，收益有限且引入风险。
对性能极其敏感的热点路径，可以考虑手动拼接。 当格式化操作处于每秒数十万次调用的核心链路中时，任何方法调用的开销都值得审视。此时，使用字符串的join方法配合列表推导，可能比任何格式化方式都更快——但代价是可读性急剧下降，仅建议在经过严格性能剖析后谨慎采用。
结语
回到最初的问题：谁才是最优解？
答案是：f-string是性能最优解，str.format()是工程最优解，百分号格式化是历史最优解。
性能测试告诉我们，技术的演进往往伴随着效率的跃迁。f-string的出现不仅仅是语法糖，它是Python解释器底层优化能力的一次集中展现。但工具的价值从来不止于速度，可读性、可维护性、兼容性同样是工程师需要权衡的维度。
在实际项目中，与其纠结于百分之几的性能差异，不如把精力放在更关键的架构决策上。选对工具，用对场景，这才是一个成熟工程师应有的判断力。
