小量拼接用+，大量拼接必须用join()；+适合模板化拼接，join()适合合并列表/生成器中的字符串，且需预先转为str，不可含None或数字。
字符串拼接用 + 还是 join()？看场景，不是看习惯
小量拼接（比如 2–3 个短字符串）用 + 完全没问题；大量拼接（尤其是循环中反复累加）必须用 ''.join()，否则性能会断崖式下跌。
根本原因在于字符串在 Python 中是不可变对象：+ 每次都新建对象，而 join() 是一次性分配内存、批量拷贝。
- 常见错误现象：
s = ''然后在for循环里写s += item，数据量一过几百就明显变慢 - 使用场景：
+适合模板化拼接（如f"Hello {name}"或"id:" + str(id)）；join()适合合并列表/生成器里的大量字符串 - 参数差异：
join()只接受一个可迭代对象，且所有元素必须是str；传入int或None会直接报TypeError: sequence item 0: expected str instance
join() 前必须把所有内容转成字符串吗？
必须。它不自动调用 str()，也不会帮你处理 None 或数字。
- 容易踩的坑：直接对
[1, 2, 3]调用'-'.join([1, 2, 3])→ 报错TypeError - 正确做法：用生成器表达式预转换，比如
'-'.join(str(x) for x in [1, 2, 3]) - 如果数据源可能含
None，别偷懒写str(x)，得显式处理：''.join(str(x) if x is not None else '' for x in data)
为什么 f-string 和 % 不在这次对比里？
因为它们和 + / join() 解决的不是同一类问题：f-string 和 % 是格式化，目标是插入值并控制输出形式；+ 和 join() 是纯拼接，不涉及格式逻辑。
- 性能上，
f-string是目前最快的格式化方式，但如果你只是把一堆已知字符串首尾连起来，它反而多了一层解析开销 - 兼容性影响：
f-string只支持 Python 3.6+；join()和+从 2.x 就存在，无兼容顾虑 - 误用示例：用
f"{a}{b}{c}{d}"替代''.join([a, b, c, d])—— 功能等价，但前者可读性略好、后者在超长列表中更稳
真实项目里最容易被忽略的点
不是选 + 还是 join()，而是「拼接动作是否真有必要」。
- 日志拼接常写成
logger.info("user=" + user + ", action=" + action)，其实应该交给日志库自己格式化：logger.info("user=%s, action=%s", user, action)—— 避免无效拼接，还支持延迟求值 - SQL 拼接看似适合
join()，但直接拼接字段名或值极危险，应交由参数化查询处理，而不是优化拼接本身 - 模板渲染（如 Jinja2）里硬写
{{ a + b + c }}，不如在上下文里预计算好full_name字段 —— 拼接逻辑下沉，视图更干净
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
