字符串+拼接在循环中极慢，因Python字符串不可变，每次+都创建新对象并触发O(n²)内存分配与垃圾回收；应改用str.join()、io.StringIO或f-string单次组装。
为什么 + 拼接字符串在循环里特别慢？
因为 Python 字符串不可变，每次 + 都会创建新对象，旧字符串被丢弃。循环 10000 次，就分配 10000 次内存，还触发多次垃圾回收——不是“有点慢”，是 O(n²) 时间复杂度。
典型症状：RuntimeWarning: line_profiler 显示 += 行耗时飙升；memory_profiler 观察到内存使用锯齿状增长。
- 适用场景：拼接次数 ≥ 100，或单次拼接内容来自循环（如日志组装、SQL 构建）
- 不适用场景：仅 2–3 次固定拼接（
"Hello" + name + "!"反而更直观） - CPython 实现细节：虽然 CPython 对相邻字面量做了优化（
"a" "b"→"ab"），但变量参与的+不享受此优化
str.join() 是什么情况下必须用的？
当所有待拼接片段已存在（列表、生成器、元组），且你知道最终要一个字符串——这是最通用、最稳的方案。它一次性预估总长度，只分配一次内存。
注意：传给 join() 的必须是字符串序列。常见错误是传入数字或 None：
立即学习“Python免费学习笔记（深入）”；
parts = ["id:", 123, ", name:", None] "".join(parts) # TypeError: sequence item 1: expected str, int found
- 修复方式：
"".join(str(x) for x in parts)或提前转换：[str(x) for x in parts] - 性能提示：如果片段来自生成器（如
(str(x) for x in data)），join()会先转成 tuple，内存开销略增；若数据极大，考虑分批join后再拼 - 兼容性：Python 2.7+ 全支持，无版本陷阱
什么时候该用 io.StringIO 而不是 list.append()？
当你需要边写边读、或中间有格式化逻辑（比如插入换行、缩进）、或拼接过程可能提前退出（带条件中断）——这时 StringIO 比维护一个 list 更自然。
list.append() 看似简单，但最后还得 "\n".join(lines)，多一次遍历；而 StringIO 的 getvalue() 直接返回字符串，底层缓冲区连续。
- 初始化开销略高（创建对象），但大文本下优势明显
- 别漏掉
import io—— 它不在 built-in 里，新手常忘 - 避免误用
io.BytesIO：处理文本必须用io.StringIO，否则类型错、编码崩
f-string 和 % 格式化适合拼接吗？
适合**单次组合**，不适合**累积拼接**。f-string 是编译期优化，每个 f-string 都是独立表达式，反复写 f"{s} {x}" 仍触发重复分配。
错误示范：
s = ""
for x in items:
s = f"{s} {x}" # 等价于 s + " " + str(x)，还是 O(n²)- 正确用法：把整个结构用 f-string 一气呵成，比如
f"User {name} logged in at {dt:%Y-%m-%d}" -
%和.format()同理，只用于终态组装，不用于循环内追加 - 唯一例外：Cython 或 PyPy 下某些场景有优化，但别依赖——CPython 主流环境里没区别
真正难的是判断“拼接是否真的必要”。有时用生成器表达式 + join 替代循环，有时干脆改用模板引擎（如 jinja2）——但那是另一层权衡了。
