python字符串不可变，+拼接需频繁新建对象，n次拼接产生n-1次拷贝，时间复杂度近O(n²)；循环中+=性能断崖下跌，应改用list.append()+””.join()。
用 + 拼接字符串时，为什么越拼越慢？
因为 Python 字符串不可变，每次 + 都会新建对象。拼接 n 个字符串，实际产生 n-1 次中间字符串拷贝，时间复杂度接近 O(n²)。
常见错误场景：在循环里反复 += 累加日志或 html 片段——小数据看不出问题，一旦字符串总长超几 KB，性能断崖式下跌。
- 适合拼接 2–3 个短字符串（如
"Hello" + name + "!"） - 避免在
for循环中使用+=构建长字符串 - 如果必须动态累积，先存入
list，最后用"".join()
str.join() 是不是永远最快？
绝大多数情况下是的，尤其当待拼接内容已存在（如列表、元组），str.join() 只需一次内存预分配和单次遍历，时间复杂度 O(n)。
但要注意：它要求所有元素都是 str 类型，否则直接报 TypeError: sequence item 0: expected str instance。
立即学习“Python免费学习笔记（深入）”；
- 拼接大量已知字符串（如日志行、csv 字段）首选
"n".join(lines) - 含非字符串元素时，先统一转
str：" ".join(map(str, data)) - 单个字符串调用
"".join([s])没有意义，反而多一层函数调用开销
f-String 和 format() 在什么场景下更合适？
f-string（Python 3.6+）本质是运行时表达式求值 + 字符串插值，不涉及拼接逻辑，性能接近直接字面量；str.format() 稍慢，但支持命名参数和复用模板。
它们的优势不在“拼接速度”，而在可读性与格式控制——比如带精度、对齐、类型转换的输出。
- 变量插值优先用 f-string：
f"User {uid} logged in at {datetime.now():%H:%M}" - 需要复用同一格式多次（如生成多行报表），用
template = "ID: {:04d}, Name: {}"配合template.format(id, name) - 避免用 f-string 拼接大量动态片段（如循环内生成 HTML 标签），应改用
list.append()+join()
为什么 % 格式化现在不推荐？
% 是 Python 最老的格式化方式，语法紧凑但扩展性差，不支持命名参数嵌套、无法直接处理 None（会抛 TypeError），且和 C 风格耦合过深，易出错。
虽然它在简单场景（如 "%s: %d" % (name, count)）仍有可读性，但和 f-string 相比毫无性能优势，还增加维护成本。
- 新代码一律避开
%，哪怕只是两个变量也用 f-string - 遗留代码中遇到
%，不要为了“统一风格”强行改成format()，优先升级为 f-string -
Logging模块仍支持%占位（如logger.info("User %s failed %d times", user, n)），这是特例，不触发字符串拼接，可保留
真正影响性能的从来不是“选哪种语法”，而是“是否在错误的抽象层做操作”——比如用字符串拼接代替模板引擎，或把本该批量处理的 IO 拆成上百次 +=。f-string 再快，也救不了在循环里拼 sql 的设计。