Python f-string 与 str.format() 的区别及选择建议

一、底层实现机制：运行时方法调用 vs 编译期原生字节码

许多初学者直观地认为 f"{name}" 只是 "{}".format(name) 的语法糖简写，但实际上两者在 CPython 解释器中的编译与运行机制完全不同。

str.format() 遵循的是常规面向对象的方法调用逻辑。解释器在执行时，首先将格式化模板作为普通字符串常量装载，然后将传入的变量打包为位置参数元组（args）或关键字参数字典（kwargs），随后通过方法查找机制调用字符串对象的 format 方法。在该方法内部，解释器每次被调用时都要重新遍历并解析占位符与格式规范说明符，最后反射获取属性并调用对应对象的 __format__ 方法拼接输出。

相比之下，f-string 是 Python 词法分析器原生识别的语言结构。在 AST（抽象语法树）解析阶段，它被拆解为 JoinedStr 和 FormattedValue 语法节点，并在编译期直接生成专用的虚拟机操作码（如 FORMAT_VALUE 和 BUILD_STRING）。在运行时，表达式直接在局部命名空间或全局命名空间中求值入栈，直接由 CPython 的求值循环在 C 语言层级完成格式转换与缓冲区合并，完全规避了函数查找、参数打包和字符串模板重复扫描的系统开销。

图 1：Python 解释器处理 str.format() 与 f-string 的底层调用与字节码生成逻辑对比

我们可以使用 Python 标准库内置的 dis 模块直观查看两者的反汇编字节码差异：

import dis

def demo_format(user, score):
    return "用户: {}, 得分: {}".format(user, score)

def demo_fstring(user, score):
    return f"用户: {user}, 得分: {score}"

print("=== demo_format 字节码 ===")
dis.dis(demo_format)

print("\n=== demo_fstring 字节码 ===")
dis.dis(demo_fstring)

在输出结果中，demo_format 需要先后执行 LOAD_CONST（加载模板字符串）、LOAD_METHOD（查找 format 方法）、LOAD_FAST（加载两个变量），再通过 CALL_METHOD 2 完成函数调用；而 demo_fstring 只有简单的 LOAD_FAST、FORMAT_VALUE 0 和最后的 BUILD_STRING 4，整个处理路径极其简洁，完全没有函数调用的额外栈帧开销。

二、核心语法与功能特性的横向对比

从代码编写与日常维护的角度来看，两者的语法表达力存在明显的分水岭。

1. 任意表达式内联求值

在 str.format() 中，花括号内部仅能识别变量标识符、属性访问（如 {obj.name}）或字典/列表索引（如 {data[0]}）。如果需要进行简单算术、函数调用或数据转换，必须在调用 format() 之前预先计算并显式传参：

# str.format() 做法：必须先在外部计算，或作为命名参数传入
price = 89.5
tax_rate = 0.08
total = price * (1 + tax_rate)
msg1 = "总金额为: {:.2f} 元".format(total)

# f-string 做法：直接在大括号内书写任意合法 Python 表达式
msg2 = f"总金额为: {price * (1 + tax_rate):.2f} 元"
msg3 = f"大写状态: {'active'.upper()}, 处理项数: {len([1, 2, 3])}"

2. 原生调试语法糖（Python 3.8+）

在开发与排查缺陷时，经常需要打印形如 "variable = value" 的日志。Python 3.8 为 f-string 增加了 = 说明符，能够自动输出变量名（包含空格与表达式文本）及其对应的值，极大降低了调试样板代码量。而 str.format() 完全不支持此类语法：

width = 1920
height = 1080

# f-string 自解释调试语法
print(f"{width=}, {height=}, {width / height = :.2f}")
# 示例输出：width=1920, height=1080, width / height = 1.78

# str.format() 若要实现相同效果必须重复输入变量名
print("width={}, height={}, width / height = {:.2f}".format(width, height, width / height))

3. 嵌套格式规范说明符

在需要动态指定浮点数保留小数位或文本填充宽度的场景中，两者均支持动态嵌套，但 f-string 的变量名在模板中一目了然：

val = 3.14159265
precision = 3
width = 10

# f-string 动态嵌套：内层大括号包裹变量
res_f = f"{val:{width}.{precision}f}"

# str.format() 动态嵌套：依赖额外的参数槽位
res_fmt = "{:{}.{}f}".format(val, width, precision)

图 2：f-string 与 str.format() 在功能特性、解耦能力及工程适用性上的全方位对比

三、运行性能实测对比与开销根源分析

为了客观验证底层的执行性能差异，我们可以使用 Python 标准库的 timeit 模块在相同硬件环境（Python 3.10+ / 64位环境）下进行基准测试。以下是测试脚本与执行方式：

import timeit

setup_code = """
name = "Antigravity"
age = 28
balance = 12580.75
"""

# 1. 测试 % 格式化（传统基准）
t_percent = timeit.timeit(
    '"User: %s, Age: %d, Balance: %.2f" % (name, age, balance)',
    setup=setup_code, number=10_000_000
)

# 2. 测试 str.format()
t_format = timeit.timeit(
    '"User: {}, Age: {}, Balance: {:.2f}".format(name, age, balance)',
    setup=setup_code, number=10_000_000
)

# 3. 测试 f-string
t_fstring = timeit.timeit(
    'f"User: {name}, Age: {age}, Balance: {balance:.2f}"',
    setup=setup_code, number=10_000_000
)

print(f"%-格式化耗时:   {t_percent:.3f} 秒")
print(f"str.format耗时: {t_format:.3f} 秒")
print(f"f-string耗时:   {t_fstring:.3f} 秒")

性能大幅提升的原因主要归结为三点：

1. 零方法查找开销：不需要在每次拼接时查询 format 属性并执行属性分派。
2. 零多余对象分配：不需要在堆上创建元组或字典来转交参数，所有参与计算的变量都在局部执行栈上直接完成读取。
3. 内联优化输出缓冲区：CPython 解释器在编译期能准确预知静态字符串片段的数量，在 C 语言层通过 _PyUnicodeWriter 预分组合并，极大地减少了内存重新分配与拷贝次数。

四、安全性边界：代码注入与不可信模板的风险防范

在评估工具时，不能仅仅关注语法糖与运行速度，安全性边界是软件架构不可忽视的底线。

1. str.format() 的对象属性遍历漏洞

因为 str.format() 允许通过点号访问对象的属性，当模板字符串来自不受信任的用户输入（例如网站前台表单、开放给用户的自定义报表模板）时，恶意攻击者可以通过 Python 的内置属性链探测全局命名空间与敏感配置：

# 危险示例：允许外部输入模板
class UserContext:
    def __init__(self, username):
        self.username = username

# 恶意用户提交的模板利用 __init__.__globals__ 获取敏感配置
malicious_template = "欢迎, {user.__init__.__globals__[SECRET_KEY]}!"
context = UserContext("guest")

# 运行此处将直接泄露内存中的 SECRET_KEY 变量
# print(malicious_template.format(user=context))

防范措施：凡是允许用户自定义模板的场景，严禁直接使用 str.format()。应改用 string.Template（仅支持 $var 替换，不支持属性反射）或专用的沙箱模板引擎（如 Jinja2 的沙箱模式）。

2. f-string 的静态特性与“伪动态”安全陷阱

有些开发者由于习惯了 f-string 的便利性，当遇到“从外部文件或数据库动态加载字符串模板”的需求时，会误用 eval() 来强行执行 f-string：

# 极度危险的代码：严禁在生产代码中使用！
external_template = request.GET.get("template") # 假设用户传入 'f"{__import__(\'os\').system(\'rm -rf /\')}"'
rendered = eval(external_template) # 导致灾难性的远程代码执行 (RCE)

安全原则：必须明确认识到 f-string 是一项源码级的语法特性，不是动态模板引擎。所有 f-string 都必须在源码编写期由开发者静态确定，绝对不能把不受信任的外部字符串包装为 f-string 交付给 eval() 执行。

五、技术选型决策路径与工程实践流程

在实际工程项目中，如何在面对不同需求时迅速做出合理选择？以下流程图给出了清晰的四步研判路径：

图 3：字符串格式化选型推导决策树与工程落地快速研判路径

六、实战选型建议与开发黄金守则

结合上述分析，在实际 Python 项目开发中，我们建议团队遵循以下工程守则：

开发中的 4 条避坑规范

1. 大括号内只保留简单表达式：虽然 f-string 语法上允许在大括号内书写复杂的列表推导式或嵌套三元表达式，但这会严重破坏代码的可读性与排版规范。如果表达式超过了一行或包含多重判断，应先将其提取为语义明确的中间变量，再放入 f-string 中。
2. 区分日志库内置延迟格式化：在标准库 logging 中，常规调试日志（如 logger.debug()）建议保留 %s 占位符机制（如 logger.debug("处理数据: %s", data)）。这是因为当日志级别高于 DEBUG 时，标准库会跳过字符串格式化计算；若直接使用 logger.debug(f"处理数据: {data}")，无论该日志是否最终输出，大括号内的表达式都会被立即计算。
3. 单行过长时的规范书写：当格式化文本较长时，利用 Python 的圆括号隐式行拼接特性保持优雅排版：

   query_summary = (
       f"订单号: {order_id} | "
       f"客户姓名: {customer_name:<10} | "
       f"应付金额: ￥{total_amount:,.2f}"
   )

4. SQL 与命令行拼接严禁使用任意字符串格式化：无论是 f-string、str.format() 还是 %，都绝对不能用于拼接 SQL 查询语句或 Shell 命令参数。SQL 必须使用数据库驱动提供的参数化查询占位符（如 cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))），Shell 命令应通过 subprocess.run(["cmd", arg1, arg2]) 列表形式传参，从源头杜绝注入漏洞。

图 4：现代 Python 格式化场景选型全景速查与工程实践守则

七、总结

在 Python 的演进历程中，从早期的 % 格式化，到 Python 2.6 引入的 str.format()，再到 Python 3.6 确立的 f-string，语言设计始终朝着“更直观的表达”与“更高效的执行”前进。

总结而言：

• 代码内联拼接，95% 以上的场景直接选择 f-string：它具备压倒性的性能优势和直观清晰的语法，配合 f"{var=}" 更是日常调试的利器。
• 需要数据解耦与模板复用时，选择 str.format()：它允许将模板定义为独立可配置的字符串变量，在需要时传入参数完成延迟渲染。
• 模板来自不受信的外部输入时，选用 string.Template 或安全沙箱：避免 str.format() 的属性链探测漏洞，更绝不能动态 eval 不可信的 f-string。

建立清晰的技术选型边界，能够确保项目既拥有现代 Python 带来的极致开发体验与执行速度，又兼备大型工程所需的健壮性与安全性。