字符串拼接用+在循环中慢因每次新建对象致O(n²)时间复杂度和高GC压力；推荐str.join()批量拼接、f-string动态格式化，避免%和format()除非兼容或需模板复用。
字符串拼接用 + 为什么在循环里特别慢
因为 + 每次拼接都会新建字符串对象，时间复杂度是 O(n²)。比如循环 10000 次拼接短字符串，实际会分配上万次内存，GC 压力大，性能断崖式下跌。
- 适合场景：拼接固定、少量（≤3 个）字符串，如
"Hello" + name + "!" - 不推荐在
for或while中累积拼接，哪怕看着简洁也别用 - CPython 下有小优化（相邻字面量自动合并），但仅限编译期，运行时无效
str.join() 的正确姿势和常见误用
join() 是批量拼接的首选，但必须传入可迭代对象，且所有元素都得是 str 类型——这点容易被忽略。
- 正确写法：
" ".join(["a", "b", "c"])，不是["a","b","c"].join(" ")（后者报AttributeError） - 数字要显式转
str：",".join(map(str, [1, 2, 3]))，否则抛TypeError: sequence item 0: expected str instance - 空列表返回空字符串：
"-".join([])→""，不会报错，但要注意逻辑是否容许
f-string 在格式化拼接中不可替代，但别滥用
f-string 不只是“更简洁的 .format()”，它是编译期解析、零运行时开销的真正优势项，但仅适用于含变量/表达式的动态拼接。
- 高效场景：
f"User {uid} logged in at {datetime.now():%H:%M}"，表达式直接求值，比.format()快约 30% - 不能用于变量分隔符或运行时模板：
sep = "-"; f"{a}{sep}{b}"可以，但若sep来自用户输入且需多次复用，不如先join() - 注意作用域：f-string 内不能访问闭包外的局部变量（除非在函数内定义），调试时容易困惑
format() 和 % 格式化现在还值得用吗
% 已被标记为 legacy，str.format() 功能全但慢——两者都涉及运行时解析格式字符串，开销明显高于 f-string 和 join()。
立即学习“Python免费学习笔记（深入）”；
-
%仅建议兼容老代码或极简场景（如"%d/%d" % (a, b)），新项目避免 -
.format()适合需要复用模板、延迟填充的场景，例如日志模板：msg_tpl = "Failed to process {item}: {reason}"，之后多次msg_tpl.format(...) - 三者性能排序（同场景下）：f-string >
join()≈+（少量） >.format()>%
真正影响选择的不是“哪种最潮”，而是数据来源（字面量？变量？列表？）、拼接频次（一次？循环中？）、是否含格式需求（对齐、进制、日期）。比如读文件逐行处理再合并，join(list_of_lines) 几乎总是最优；而生成 SQL 片段，f-string 配合参数校验更安全——别让习惯代替判断。
