字符串拼接时反复使用+会变慢，因python字符串不可变，每次+都创建新对象；建议循环中用list.append()收集再join()合成。
字符串拼接时反复 + 会变慢
Python 的字符串是不可变对象，每次用 + 拼接都会创建新字符串，旧字符串若无引用会被回收。这意味着 s = s + "a" 在循环里执行 10000 次，实际分配了约 10000 个新字符串对象，内存和时间开销都线性增长。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 循环内拼接优先用
list.append()收集片段，最后用" ".join()一次性合成 - 已知片段数量少（+ 可读性高且差异不明显，不用强改
- 用
io.StringIO适合流式构建（如生成 HTML 片段），但要注意它不是字符串，需显式调用.getvalue()
str.replace() 和 re.sub() 修改多次的开销在哪
因为字符串不可变，"a b c".replace(" ", "-").replace("a", "x") 实际创建了三个中间字符串：原始串 → "a-b-c" → "x-b-c"。每调用一次方法，就触发一次完整复制。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 多步替换能合并就合并：用
re.sub(r"[ab]", lambda m: {"a":"x","b":"y"}[m.group()])替代链式replace() - 正则替换本身有编译开销，频繁调用记得预编译
re.compile()，避免重复解析模式 - 如果只是删/替固定子串且不涉及逻辑，
str.translate()是最快选择（需配合str.maketrans()构建映射表）
函数参数传入字符串后被“修改”？其实是变量重新绑定
不可变性常被误解为“不能改内容”，但真正关键的是：你无法原地修改一个 str 对象的内容。所有看似“修改”的操作，本质都是让变量指向新对象。
常见错误现象：
- 写了个函数
def append_suffix(s, suf): s += suf，调用后原变量没变——因为s += suf是给形参s重新赋值，不影响外部变量 - 误以为
list里的字符串能被“就地更新”，其实my_list[0] += "!"是把列表索引位置重新赋值，不是改字符串本身
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 需要返回新值就明确
return s + suf，别指望副作用 - 如果真要模拟“可变字符串”行为（比如解析器内部缓冲），用
bytearray（字节）或array.array('u')（Unicode 字符）更合适，但注意它们不兼容str接口
为什么 f-string 和 str.format() 性能比 % 好
三者最终都生成新字符串，但底层实现不同：% 需要解析格式字符串、匹配占位符、类型检查；str.format() 多一层解析器和位置/命名参数处理；而 f-string 在编译期就把表达式固化为字节码，运行时只做求值+拼接，跳过了大部分解析开销。
性能影响：
- 简单场景（如
f"hello {name}"）比"hello {}".format(name)快 20%~30%，比"hello %s" % name快约 10% - 嵌套表达式（如
f"{obj.method().attr}"）仍需运行时求值，但解析部分已省掉 -
%格式在 Python 3.12+ 已标记为 deprecated，新代码避免使用
不可变性在这里不制造额外负担，但选错工具会让本可避免的开销变得明显。
真正容易被忽略的是：所有这些拼接方式，只要结果长度远大于输入，就会触发内存重分配。如果提前知道大致长度（比如日志行固定前缀+时间戳+ID），用 bytearray 预分配再写入，才是突破字符串不可变限制的务实做法。
