f-String 比 + 拼接快得多，因其在编译期完成求值与组装，不生成中间字符串；而 + 每次都创建新字符串，循环中导致 O(n²) 内存复制，1000 次拼接可慢 5–10 倍。
为什么 f-string 比 + 拼接快得多
因为 f-string 在编译期就完成表达式求值和字符串组装，不生成中间字符串对象；而 + 每次拼接都创建新字符串（python 字符串不可变），在循环中会引发 O(n²) 内存复制。比如拼接 1000 个短字符串时，+ 可能比 f-string 慢 5–10 倍。
实操建议：
- 单次拼接或少量变量：优先用
f-string（如f"Hello {name}"） - 避免在 for 循环里用
+=拼接字符串，尤其当拼接次数 > 100 - 若必须动态累积，改用
list.append()+''.join()
''.join() 适合什么场景
当你要把大量已知片段（比如列表里的几百个字符串）一次性合并时，''.join() 是最优解。它底层调用 C 实现的高效内存预分配，时间复杂度接近 O(n)。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 写成
result = result + item替代parts.append(item)→ 性能断崖式下跌 - 误用
str.join()的调用者：必须是分隔符字符串调用，不是列表调用（即'-'.join(my_list)✅，my_list.join('-')❌） - 传入非字符串元素（如
[1, 2, 3]）会直接报TypeError: sequence item 0: expected str instance, int found
% 格式化和 str.format() 还值得用吗
两者均已过时，仅建议用于兼容旧代码。它们比 f-string 多一层解析开销，且 str.format() 在处理嵌套表达式或条件逻辑时语法笨重（比如不能直接写 {x if x > 0 else 'no'}，而 f-string 可以）。
性能差异明显：
- 在 CPython 3.12 下，相同模板下
f-string比str.format()快约 30%–40% -
%格式化对字典键名敏感，%(name)s中的name必须存在于字典里，否则抛KeyError，而f-string报的是更清晰的NameError - 如果模板来自不可信输入（如用户提交的格式串），
f-string不支持运行时注入，反而更安全 —— 但此时也不该用任何模板，应走专用渲染引擎
多行字符串拼接的隐藏陷阱
用括号隐式连接（"a" "b" "c"）看似简洁，但它只适用于字面量，无法嵌入变量或表达式；一旦混入 f-string 或函数调用，就必须显式用 + 或换行加反斜杠，反而破坏可读性。
实操建议：
- 纯静态文本跨行：直接用三引号
"""...，不要拆成多个"..." "..." - 含变量的多行拼接：统一用
f-string配合n或三引号内插值（f"""line1 {x}nline2"""） - 生成 sql 或 jsON 片段时，别依赖隐式拼接 —— 看似省事，但缩进、换行符、空格易出错，且 ide 无法校验语法
真正影响性能的往往不是“选哪个语法”，而是拼接是否发生在热路径上、是否意外触发重复计算或隐式类型转换。比如 f"{obj.name} {str(obj.id)}" 里多余的 str() 调用，在高频日志中也会累积可观开销。