4. 字符串优化：字符串驻留机制、f-string vs format vs % 的性能与内存

字符串优化，说实话，是内存优化里最容易被忽视的一块。很多人觉得字符串嘛，不就是一堆字符，能占多少内存？我见过一个线上服务，光字符串对象就占了堆内存的 40%。那次排查让我印象深刻——从那以后，我对字符串的每一个字节都格外敏感。

这一章我们聊三个核心点：字符串驻留机制、三种格式化方式的性能差异、以及实际项目中的避坑指南。

4.1 字符串驻留机制：Python 的“共享单车”

Python 有个小秘密——它会对某些字符串做“驻留”（intern）。说白了，就是相同的字符串只存一份，多个变量引用同一个对象。这有点像共享单车：车只有一辆，但谁都能骑。

看个例子：

# 这两个变量指向同一个对象
a = "hello_python"
b = "hello_python"
print(a is b)  # True —— 驻留了

# 但动态生成的就不一定了
c = "hello_" + "python"
print(a is c)  # True —— 编译期常量折叠

d = "".join(["hello_", "python"])
print(a is d)  # False —— 运行时生成，不驻留

为什么会这样？因为 join 是在运行时执行的，Python 没法在编译期确定结果。我遇到过一个问题：用 join 拼接大量重复的短字符串，内存直接爆了。后来改用 sys.intern 手动驻留，内存降了 30%。

import sys

# 手动驻留
sql_template = sys.intern("SELECT * FROM users WHERE id = %s")
for i in range(10000):
    # 每次循环都引用同一个字符串对象
    execute(sql_template, i)

4.2 三种格式化方式：f-string、format、%

Python 里格式化字符串有三种主流方式：% 操作符、str.format()、以及 f-string。很多人觉得它们只是语法糖，选哪个都行。但性能上，差距还挺大的。

方式	语法示例	执行速度	内存开销	适用场景
% 操作符	"name: %s" % name	较慢	中等	遗留代码、日志模板
str.format()	"name: {}".format(name)	中等	较高	需要复用模板、动态格式化
f-string	f"name: {name}"	最快	最低	绝大多数场景

我做过一个基准测试，循环 100 万次：

import timeit

name = "Alice"
age = 30

# % 操作符
t1 = timeit.timeit(
    '"Name: %s, Age: %d" % (name, age)',
    globals=globals(), number=1_000_000
)

# str.format()
t2 = timeit.timeit(
    '"Name: {}, Age: {}".format(name, age)',
    globals=globals(), number=1_000_000
)

# f-string
t3 = timeit.timeit(
    'f"Name: {name}, Age: {age}"',
    globals=globals(), number=1_000_000
)

print(f"%: {t1:.3f}s")
print(f"format: {t2:.3f}s")
print(f"f-string: {t3:.3f}s")

结果大致是：f-string 比 % 快 2-3 倍，比 format 快 4-5 倍。为什么？因为 f-string 是编译期求值的，它直接生成字节码，没有额外的函数调用开销。而 format 需要解析模板字符串，% 操作符也有方法调用的开销。

import logging

# 不好的做法：f-string 总是求值
logging.debug(f"User data: {expensive_function()}")

# 好的做法：% 操作符延迟求值
logging.debug("User data: %s", expensive_function())

4.3 内存视角：字符串对象的隐藏开销

每个 Python 字符串对象，除了字符数据本身，还有额外的元数据开销。我算过，一个空字符串就占 49 字节（CPython 3.10+）。这包括引用计数、类型指针、哈希值、长度、编码信息等。

你想想看，如果你有 10 万个短字符串，每个 5 个字符，实际数据才 500KB，但对象开销可能超过 5MB。这就是为什么字符串驻留能省内存——它减少了对象的数量。

4.4 实战：字符串拼接的陷阱

我曾经接手过一个项目，里面大量使用 str1 + str2 拼接字符串。在循环里，这种写法会产生大量临时对象。每次拼接都创建一个新字符串，旧字符串变成垃圾等待回收。

看这个对比：

# 坏做法：每次循环创建新对象
result = ""
for i in range(10000):
    result += str(i)  # 创建 10000 个临时字符串

# 好做法：用列表收集，最后 join
parts = []
for i in range(10000):
    parts.append(str(i))
result = "".join(parts)  # 只创建 1 个新字符串

用 join 的方式，内存分配次数从 10000 次降到 1 次。我优化过一个日志聚合模块，把 += 改成 join 后，内存占用从 200MB 降到 40MB。

4.5 知识体系图

下面这张图总结了字符串优化的核心逻辑：

4.6 避坑指南

最后，分享几个我踩过的坑：

• 别在循环里用 + 拼接字符串——时间复杂度 O(n²)，内存碎片化严重。用 join 替代。
• f-string 不是万能的——日志场景用 % 操作符，避免不必要的表达式求值。
• 别滥用 sys.intern——只对重复出现且生命周期长的字符串使用。短命字符串驻留反而增加 GC 压力。
• 注意 Unicode 字符串——中文字符每个占 2-4 字节，别按 ASCII 估算内存。