Python字符串不可变,+拼接需频繁新建对象,n次拼接产生n-1次拷贝,时间复杂度近O(n²);循环中+=性能断崖下跌,应改用list.append()+"".join()。
+ 拼接字符串时,为什么越拼越慢?因为 Python 字符串不可变,每次 + 都会新建对象。拼接 n 个字符串,实际产生 n-1 次中间字符串拷贝,时间复杂度接近 O(n²)。
常见错误场景:在循环里反复

+= 累加日志或 HTML 片段——小数据看不出问题,一旦字符串总长超几 KB,性能断崖式下跌。
"Hello" + name + "!")for 循环中使用 += 构建长字符串list,最后用 "".join()
str.join() 是不是永远最快?绝大多数情况下是的,尤其当待拼接内容已存在(如列表、元组),str.join() 只需一次内存预分配和单次遍历,时间复杂度 O(n)。
但要注意:它要求所有元素都是 str 类型,否则直接报 TypeError: sequence item 0: expected str instance。
"\n".join(lines)
str:" ".join(map(str, data))
"".join([s]) 没有意义,反而多一层函数调用开销format() 在什么场景下更合适?f-string(Python 3.6+)本质是运行时表达式求值 + 字符串插值,不涉及拼接逻辑,性能接近直接字面量;str.format() 稍慢,但支持命名参数和复用模板。
它们的优势不在“拼接速度”,而在可读性与格式控制——比如带精度、对齐、类型转换的输出。
f"User {uid} logged in at {datetime.now():%H:%M}"
template = "ID: {:04d}, Name: {}" 配合 template.format(id, name)
list.append() + join()
% 格式化现在不推荐?% 是 Python 最老的格式化方式,语法紧凑但扩展性差,不支持命名参数嵌套、无法直接处理 None(会抛 TypeError),且和 C 风格耦合过深,易出错。
虽然它在简单场景(如 "%s: %d" % (name, count))仍有可读性,但和 f-string 相比毫无性能优势,还增加维护成本。
%,哪怕只是两个变量也用 f-string%,不要为了“统一风格”强行改成 format(),优先升级为 f-stringlogging 模块仍支持 % 占位(如 logger.info("User %s failed %d times", user, n)),这是特例,不触发字符串拼接,可保留+=。f-string 再快,也救不了在循环里拼 SQL 的设计。