一、历史脉络：为什么会有三种方式？

Python 的字符串格式化演进史，本质上是一门语言不断追求表达力与性能平衡的缩影。

% 格式化是最古老的方式，其设计灵感源自 C 语言的 sprintf 函数。Python 早期直接沿用了这一语法，将其内置到字符串类型中。由于出现最早、使用最广，它在大量遗留系统中至今仍占据主导地位。

str.format() 于 Python 2.6 引入，Python 3 时代全面铺开。它的出现是为了解决 % 格式化在复杂场景下表达力不足的问题，比如无法方便地通过索引或名称引用参数、无法自定义格式化规则等。它借鉴了 C# 和 Java 的格式化思想，提供了更丰富的特性集。

f-string（格式化字符串字面值）在 Python 3.6 横空出世，由 PEP 498 正式定义。它的核心理念是将表达式直接嵌入字符串字面值中，由解释器在编译阶段完成求值。这一设计让格式化语法回归简洁，同时在性能上实现了质的飞跃。

三种方式并存至今，并非设计失误，而是 Python 社区"向后兼容"原则的体现。每一种都有其不可替代的价值，关键在于如何在合适的场景选择合适的工具。

二、% 格式化：老当益壮的经典

% 格式化使用百分号作为占位符，后跟一个字符表示类型，例如 %s 表示字符串、%d 表示整数、%f 表示浮点数。它支持两种传参方式：一种是按位置的元组传参，另一种是按名称的字典传参。

优势在于简洁。 对于最基础的字符串拼接场景，% 格式化的写法极为短小，几个字符就能完成任务。它在日志输出、简单模板渲染等场景中依然拥有极高的使用频率。

劣势同样明显。 当需要格式化的参数较多时，% 格式化的可读性会急剧下降。因为占位符与实际参数之间是松散耦合的，开发者必须在脑海中维护"第一个 %s 对应第一个参数"这样的映射关系。一旦参数顺序调整，极易引入难以察觉的错误。此外，% 格式化不支持在占位符内部直接进行表达式运算，所有计算必须在格式化之前完成。

值得一提的是，% 格式化还有一个衍生变体：使用字典配合 % 操作符进行命名替换。这种方式在一定程度上弥补了位置参数的不足，但语法依然较为繁琐，远不如后来的方案直观。

三、str.format()：功能至上的中庸之道

str.format() 引入了花括号作为占位符，并通过冒号后跟格式规范来控制输出样式。它最大的革新在于支持两种引用方式：位置索引和关键字命名。

位置索引允许通过数字指定参数顺序，比如第一个花括号对应第零个参数。关键字命名则允许直接通过参数名引用，彻底解决了 % 格式化中参数顺序与占位符顺序必须严格一致的痛点。

str.format() 的真正威力在于格式规范迷你语言。 在冒号之后，可以指定对齐方式（左对齐、右对齐、居中）、填充字符、数字精度、进制转换、千分位分隔等丰富选项。这使得它在生成报表、输出表格、构建固定格式文本时表现出色。

然而，str.format() 也有其代价。语法冗长是最常被诟病的一点。即使是最简单的变量替换，也需要写出完整的方法调用。当多个变量需要拼接时，花括号与参数之间的对应关系虽然比 % 清晰，但依然不够直观。

此外，str.format() 在运行时才进行字符串解析和拼接，这意味着它无法享受编译期优化，性能表现不及后来居上的 f-string。

四、f-string：性能与优雅的集大成者

f-string 以字母 f 或 F 开头，在字符串字面值前添加前缀，花括号内直接写入变量名或表达式。解释器会在编译阶段将花括号内的内容替换为对应的值，最终生成的字节码中不包含任何运行时的格式化操作。

f-string 的核心优势有三个。

第一，极致简洁。变量名直接写入花括号，无需任何额外的方法调用或占位符标记。多个变量拼接时，上下文一目了然，可读性在三种方式中遥遥领先。

第二，表达式求值。花括号内不仅可以放变量名，还可以放任意合法的 Python 表达式，包括算术运算、函数调用、三元表达式等。这一特性让 f-string 拥有了远超另外两种方式的表达力。

第三，性能卓越。由于格式化工作在编译阶段完成，f-string 的执行速度比 str.format() 快约百分之三十到五十，比 % 格式化也有明显优势。在高频调用的场景下，这种性能差异会被显著放大。

f-string 的局限同样值得关注。 它不支持在花括号内部使用与外部字符串相同的引号字符（虽然可以通过转义解决，但会降低可读性）。此外，f-string 的花括号内不能出现反斜杠，这限制了某些特殊场景的使用。在需要延迟求值的场景中（比如日志框架中希望在真正输出时才计算变量值），f-string 会在定义时就完成求值，可能导致不必要的计算开销。

五、横向对比：五个维度的全面对决

维度一：性能

f-string 居于首位，原因是其在编译阶段完成拼接，运行时几乎零开销。str.format() 居中，需要在运行时解析格式字符串并执行方法调用。% 格式化虽然也是运行时操作，但由于其底层实现经过长期优化，在简单场景下与 str.format() 差距不大，但在复杂场景下略逊一筹。

维度二：可读性

f-string 毫无疑问排名第一。变量就在它该出现的位置，上下文高度一致。str.format() 排名第二，命名参数让对应关系清晰可辨，但方法调用的语法本身增加了视觉噪声。% 格式化排名末位，尤其在参数超过三个时，代码几乎不可读。

维度三：表达力

f-string 支持表达式求值，在这一维度上独树一帜。str.format() 凭借其格式规范迷你语言，在数字格式化、对齐填充等场景中拥有独到优势。% 格式化的表达力最为有限，仅能满足基础的类型转换需求。

维度四：向后兼容性

% 格式化兼容所有 Python 版本，包括仍在使用的 Python 2.7。str.format() 从 Python 2.6 开始支持。f-string 仅限 Python 3.6 及以上版本。在需要支持老旧环境的项目中，% 格式化和 str.format() 依然是必要的选择。

维度五：调试友好度

f-string 在 Python 3.8 引入了一个杀手级特性：在花括号内使用等号，可以同时输出变量名和变量值。这在调试场景中极为实用，无需额外编写日志语句即可看到变量的实时状态。str.format() 和 % 格式化均不具备此能力。

六、底层机制：为什么 f-string 更快？

要理解三者的性能差异，必须深入字节码层面。

% 格式化和 str.format() 在运行时都需要经历相同的流程：解析格式字符串、定位占位符、提取参数、执行类型转换、拼接结果。这一系列操作全部在运行时完成，开销不可忽视。

f-string 则完全不同。当 Python 编译器遇到以 f 开头的字符串时，它会立即对花括号内的表达式进行求值，并将结果直接嵌入到常量字符串中。生成的字节码中，花括号的位置已经被替换为实际的值，运行时只需执行简单的字符串拼接甚至直接使用常量。这就是 f-string 速度优势的根本来源——它把本该在运行时完成的工作，提前到了编译阶段。

七、实战建议：如何选择？

基于以上分析，以下是不同场景下的推荐策略：

日常开发的首选：f-string。 只要项目运行在 Python 3.6 以上，f-string 应当成为默认选择。它在性能、可读性和表达力三个维度上全面占优。

需要兼容老版本：str.format()。 当项目必须支持 Python 3.5 及以下版本时，str.format() 是最佳替代方案。它比 % 格式化更安全、更易读，且功能足够丰富。

遗留系统维护：% 格式化。 在大量使用 % 格式化的老旧代码中，不建议强行重构。除非该段代码正在进行重大修改，否则维持现状是成本最低的选择。

日志框架场景：谨慎使用 f-string。 许多日志库（如标准库的 logging 模块）在默认配置下会对日志消息进行延迟格式化。如果使用 f-string，变量会在日志语句执行时就被求值，即使该日志最终被过滤掉不输出，计算开销也已经发生。此时使用 % 格式化或 str.format() 配合延迟求值机制更为合适。

报表与固定格式输出：str.format() 依然有一席之地。 其格式规范迷你语言在处理对齐、精度、进制转换等需求时，语法依然比 f-string 中的等价写法更为紧凑。

结语

三种字符串格式化方式并非新旧替代的关系，而是各有所长的互补关系。% 格式化是根基，str.format() 是桥梁，f-string 是未来。作为开发者，真正需要掌握的不是"哪种最好"，而是"在什么场景下该用哪种"。将这种选择能力内化为编码直觉，才是从会写代码到写好代码的关键一步。在性能敏感的路径上优先使用 f-string，在兼容性约束下退守 str.format()，在遗留系统中尊重 % 格式化的历史地位——这就是工业级开发应有的务实态度。