Python f-string、format()与%格式化对比：哪种方式更好用？

Nora

发布时间：2026-10-27 | 3人浏览过

原创

在编写 Python 程序时，将变量、数值计算结果或对象属性整合到文本中是几乎每天都会遇到的需求。假设你正在为一个监控系统生成告警通知，需要将服务名称、当前延迟时间以及时间戳组合成一条完整的推送文本。此时，Python 为你提供了三种主要方案：早期源自 C 语言传统的 % 格式化运算符、Python 2.6 引入的 str.format() 方法，以及 Python 3.6 带来的格式化字符串字面量（即 f-string）。

直接给出核心结论：在 Python 3.6 及更新的现代版本中，日常开发的首选答案是 f-string。无论是从编写体验、视觉可读性，还是底层编译执行效率来看，f-string 均具有明显优势。不过，str.format() 在处理动态模板配置、延迟绑定和国际化多语言翻译时仍然保留了独特价值；而传统的 % 格式化除了在旧系统代码维护以及标准库 logging 的延迟求值场景外，已经不再推荐用于新业务代码。

一、三种格式化语法的演进与基本用法

理解这三种语法的差异，首先需要掌握它们各自的书写方式与参数绑定机制。我们通过同一个“服务器状态提示”的构造过程来进行直接比对。

1. % 格式化（printf 风格）

% 格式化是 Python 最古老的字符串格式化语法，其设计哲学直接借鉴了 C 语言中的 printf 函数。它使用 %s、%d、%f 等格式说明符作为占位标记，并在字符串外部使用 % 运算符传入元组或单个变量。

# 示例：基础 % 格式化
service = "payment-api"
latency = 128.456
error_count = 3

message = "服务 [%s] 延迟: %.1fms，异常数: %d" % (service, latency, error_count)
# 输出: 服务 [payment-api] 延迟: 128.5ms，异常数: 3

这种方式的痛点在于：参数必须在字符串末尾按严格顺序排列；当参数较多时，阅读者需要在左侧模板和右侧元组之间反复来回对应。此外，如果传参忘记包成元组，极易引发 TypeError: not enough arguments for format string 等隐蔽错误。

2. str.format() 格式化方法

为了解决 % 语法的生硬和易错问题，Python 2.6 推出了 str.format()。它使用大括号 {} 作为占位符，支持按位置索引（如 {0}、{1}）、重复引用同一参数，以及通过具名关键字参数传递。

# 示例：str.format() 关键字传参与位置传参
message = "服务 [{name}] 延迟: {lat:.1f}ms，异常数: {err}".format(
    name=service,
    lat=latency,
    err=error_count
)

format() 的优势是解耦了模板定义与实际数据赋值。模板可以作为常量或配置文件提前定义好，待数据准备就绪后再调用 .format(**data) 进行填充。但其缺点也很直观：具名调用需要把变量名重复书写两次，代码显得较为冗长。

3. f-string（格式化字符串字面量）

Python 3.6 引入的 PEP 498 正式带来了 f-string。只需在字符串前缀加上 f 或 F，即可直接将变量甚至合法的 Python 表达式嵌入到 {} 之中。

# 示例：f-string 极简语法与表达式支持
message = f"服务 [{service}] 延迟: {latency:.1f}ms，异常数: {error_count}"

# 支持直接计算与函数调用
alert = f"状态: {'告警' if latency > 100 else '正常'} | 翻倍开销: {latency * 2:.1f}"

f-string 将数据定义与视觉输出高度结合，读代码时所见即所得，彻底消除了“左边看模板、右边找变量”的割裂感。

Python f-string、format()与%格式化对比：哪种方式更好用？ — 图 1：Python 字符串格式化语法演进与解析流程对比

二、核心维度深度横向评测

要全面衡量哪种方式更好用，不能仅看语法长相，还需要从可读性、执行性能、表达式计算能力以及调试便捷度等多个维度展开综合评估。

1. 可读性与排版维护对比

在工程项目中，代码的可维护性往往比打字速度更重要。假设我们需要格式化一段包含 5 个变量的 SQL 查询日志或调试输出：

使用 % 格式化：如果需要改变参数顺序，必须同时调整模板里的 %s 占位符和末尾元组里的变量顺序，一旦漏掉一个或者类型写错，就会抛出异常。
使用 format()：如果使用匿名 {}，面临与 % 同样的错位隐患；若使用具名参数 {table} ... format(table=table, ...)，参数列表会极度冗长，占用大量垂直屏幕空间。
使用 f-string：变量名直接放在大括号内，上下文关系紧密。修改时只需更改对应大括号内的名称，绝不会发生“左边少一个、右边多一个”的对齐难题。

2. 执行性能与底层字节码原理

许多开发者潜意识里认为字符串格式化只是简单的字符拼接，性能差异可以忽略不计。但实际上，f-string 的运行速度通常比 format() 快 2 至 3 倍，比 % 格式化快 1.5 倍以上。

这种巨大差距来自于它们底层实现机制的根本不同：

% 格式化在每次执行时，Python 解释器都要在运行时解析格式字符串，解析其中的类型指令并与元组做映射。
str.format() 本质上是一次常规的 Python 方法调用。它需要经过属性查找（.format）、函数参数压栈、字典解构、以及逐个字符扫描大括号的运行时开销。
f-string 并不是普通字符串，而是由 Python 词法分析器在编译阶段就拆解好的语法结构。解释器直接生成 FORMAT_VALUE 和 BUILD_STRING 字节码指令，运行时直接在 C 语言层面提取变量并极速构建最终字符串。

3. 表达能力与调试支持

除了性能，f-string 的语法表达力也彻底拉开了与前两者的差距：

行内计算：你可以在 {} 内直接书写算术运算、三元表达式、方法调用甚至切片，例如 f"用户总数: {len(users):,}"。
等号快速调试（Python 3.8+）：在调试输出变量时，过去我们常常书写 print("user_id =", user_id)。而在 f-string 中，只需写 f"{user_id=}"，输出即为 user_id=1024，兼具变量名和当前求值，在日常打印日志时极为高效。
多行格式化：结合括号或三引号，f-string 可以非常整洁地跨行排版复杂文本，不必像 % 那样在最下方挂着冗长难辨的元组。

三、常见格式化场景与重构指南

在实际编码中，格式化不仅涉及简单替换，往往还需要控制小数精度、千分位、对齐填充等展示样式。下面我们对照具体业务场景，说明如何将旧代码平滑重构为现代 f-string。

1. 常见样式格式说明符对照

目标效果	% 格式化	str.format()	f-string 推荐写法
保留两位小数	`"%.2f" % val`	`"{:.2f}".format(val)`	`f"{val:.2f}"`
百分比输出 (如 85.5%)	`"%.1f%%" % (val * 100)`	`"{:.1%}".format(val)`	`f"{val:.1%}"`
千分位分隔 (如 1,234,567)	不支持直接指定	`"{:,}".format(num)`	`f"{num:,}"`
补零对齐 (8位宽前置补零)	`"%08d" % num`	`"{:08d}".format(num)`	`f"{num:08d}"`
右对齐/左对齐 (指定列宽)	`"%-10s \| %10s" % (a, b)`	`"{:<10} \| {:>10}".format(a, b)`	`f"{a:<10} \| {b:>10}"`
十六进制与二进制	`"%x \| %o" % (n, n)`	`"{:x} \| {:b}".format(n, n)`	`f"{n:x} \| {n:b}"`

2. 代码重构的标准步骤

将遗留代码中的旧式格式化升级为 f-string 时，建议遵循以下四个确定的步骤进行重构：

扫描并匹配参数映射：首先看清末尾传入的变量元组或 format() 参数，确定每个占位符实际对应的数据源。
在占位符内就地内嵌变量：把原本放在外围的变量名直接剪切填入大括号内，同时去除外部的 % (...) 或 .format(...)。
格式规范迁移：将原本的格式控制符转换至冒号后。例如 %0.2f 转换为 {val:.2f}；%10s 转换为 {val:>10}。
字符转义与边界检查：如果原字符串中本身包含大括号 { 或 }（如构建 JSON 或 CSS 文本），需要将其双写转义为 {{ 或 }}。

四、选型边界与特殊场景避坑

尽管 f-string 在大部分情况下是绝对的最优解，但并不意味着 format() 和 % 应该被全盘抹杀。在软件工程中，了解工具的适用边界与反模式同样至关重要。

1. 依然适合使用 str.format() 的特殊场景

场景一：预定义的外部动态模板。
f-string 是“在定义时立即求值”的。这意味着在声明 f"..." 的那一瞬间，大括号里的变量必须在当前作用域中已经存在。如果你的模板来自数据库、YAML 配置文件、用户自定义输入或外部多语言 i18n 资源文件，变量在模板加载时尚不存在，此时必须使用 str.format()：

# 适用 format()：从外部配置加载的动态模板
template_from_db = "您好 {username}，您的订单 {order_id} 正在配送中。"

# 后续从消息队列收到事件后再进行渲染
event_data = {"username": "张三", "order_id": "ORD-20261026"}
final_sms = template_from_db.format(**event_data)

2. 依然适合使用 % 格式化的特殊场景

场景二：Python 标准库 logging 模块。
在打印日志时，常常看到官方文档推荐这样写：

import logging

# 推荐：利用 logging 内部的惰性延迟求值（Lazy Evaluation）
logging.debug("处理耗时对象: %s", heavy_object)

# 不推荐在 DEBUG 日志中直接使用 f-string：
# logging.debug(f"处理耗时对象: {heavy_object}")

为什么？因为若直接传入 f"..."，无论当前日志级别是否开启了 DEBUG，Python 都会在调用前立即把 heavy_object 转换为字符串。如果对象转换开销巨大，而当前生产环境只开启了 WARNING 级别，就会造成严重的 CPU 和内存浪费。传 % 参数给 logging 时，只有当日志级别真正符合输出要求时，底层才会触发格式化。

注意事项与防踩坑清单：

大括号转义：在 f-string 中要输出纯文本的大括号 { 或 }，必须连续输入两个大括号 {{ 或 }}。
避免过载业务逻辑：虽然 f-string 允许写复杂表达式，但切忌在 {} 内塞入多层三元运算、长列表推导或副作用函数调用，否则会严重破坏代码可读性。过于复杂的逻辑应先赋给独立变量。
引号冲突：若外部使用双引号 f"..."，内部访问字典键时建议使用单引号 {data['name']}，避免词法冲突。

五、综合对比与选型决策

为帮助你在实际项目中快速做出正确决策，下方的决策流程图与总结矩阵归纳了不同业务需求下的最佳选择路径：

六、总结

回顾 Python 字符串格式化的发展历程，从早期对 C 语言 printf 的简易模仿（% 格式化），到中期面向对象风格的探索（str.format()），再到 Python 3.6 迎来现代化的语言级集成（f-string），每一次迭代都在显著降低开发者的认知负担并提升执行性能。

在当前的 Python 开发生态中，f-string 凭借卓越的执行速度、直观的阅读体验以及强大的行内表达式能力，无疑是日常开发中更好用、更推荐的方式。建议在团队协作与新项目开发中确立统一规范：默认优先采用 f-string，在遇到动态外置模板时退行至 format()，在标准日志调用中保留延迟求值的 % 参数，以此兼顾开发效率、代码健壮性与系统运行性能。