小吴那天写了一个日志格式化工具，需要把一批用户数据拼成一条完整的日志记录。逻辑很简单：遍历用户列表，把每个用户的信息拼成一个字符串，中间用逗号隔开。代码大概长这样：
users = ["Alice", "Bob", "Charlie", "David"]
result = ""
for user in users:
result = result + user + ", "
print(result)
跑出来结果是对的：
Alice, Bob, Charlie, David,
末尾多了一个逗号加空格，但这只是小问题。小吴没太在意，继续往下写。后来数据量从几十个用户变成了几万个用户，这段代码突然变得奇慢无比。他盯着屏幕等了十几秒，才看到结果打印出来。
他以为是数据量太大导致的，直到同事路过看了一眼，说：“你这里用+拼字符串，数据量大了当然慢。换成join试试。”
小吴把代码改成：
result = ", ".join(users)
一瞬间就跑完了。他愣住了：“同样都是拼字符串，差距有这么大？”
答案是：有，而且非常大。
这个坑的根源，是很多人把+和join当成“差不多”的两种写法，却不知道它们在底层实现上完全不同。数据量小的时候看不出来，数据量一大，性能差距就是几十倍甚至上百倍。
先看一个最直观的对比
users = ["Alice", "Bob", "Charlie", "David"]
# 方式一：用 + 拼接
result1 = ""
for user in users:
result1 += user + ", "
# 方式二：用 join 拼接
result2 = ", ".join(users)
print(result1) # Alice, Bob, Charlie, David,
print(result2) # Alice, Bob, Charlie, David
结果看起来差不多（join更干净，没有末尾多余的逗号），但过程完全不同。
+的做法是：每次循环都创建一个新的字符串，把旧字符串和新内容复制进去。循环几次，就创建几个新字符串。
join的做法是：先算出最终字符串需要多长，一次性分配好内存，然后把所有片段依次填进去。只创建一次字符串。
用一个生活场景来理解。你有一堆木板，要拼成一张桌子。
+的做法是：拿一块木板，钉上第二块，得到一张小桌子。然后把小桌子拆了，重新钉上第三块，得到一张稍大的桌子。再拆了，钉上第四块……每加一块木板，就要把之前所有的木板重新拼一遍。
join的做法是：先量好所有木板的尺寸，算出总长度，准备好足够的材料，然后一次性把所有木板拼上去。
区别一目了然：一个是反复拆了重做，一个是一次性完成。
为什么 + 拼接这么慢？
要理解这个问题，得先知道Python的字符串是不可变的。
不可变的意思是：一旦创建了一个字符串，就不能修改它的内容。你不能在字符串末尾追加字符，也不能删除中间的字符。任何“修改”字符串的操作，实际上都是创建了一个新字符串。
s = "hello"
s += " world"
这行代码看起来是在"hello"后面追加" world"，但实际上发生了三件事：
第一，创建一个新字符串，内容是"hello world"。
第二，把变量s指向这个新字符串。
第三，原来的"hello"字符串如果没有其他引用，就会被垃圾回收。
所以每次+=，都会创建一个全新的字符串，并把旧字符串的内容复制过去。
在循环里，这意味着：
result = ""
for user in users:
result += user + ", "
第一次循环：创建"Alice, "，复制0个字符（旧字符串是空的）。
第二次循环：创建"Alice, Bob, "，复制7个字符。
第三次循环：创建"Alice, Bob, Charlie, "，复制15个字符。
第四次循环：创建"Alice, Bob, Charlie, David, "，复制24个字符。
每次循环都要复制之前积累的所有内容。如果循环n次，第i次复制i个字符，总复制量是1+2+3+...+n，也就是O(n²)。
n=10000时，总复制量大约是5000万个字符。这就是为什么几万条数据会卡十几秒。
join 为什么快？
join的做法完全不同。
result = ", ".join(users)
join先遍历一遍users，算出所有字符串的总长度，加上分隔符的长度，得到最终字符串需要的总空间。然后一次性分配内存，把所有片段依次复制进去。
每个字符只被复制一次，总复制量是O(n)。没有重复复制，没有中间字符串，没有垃圾回收。
n=10000时，总复制量就是几万个字符。和+方式的5000万次复制相比，差距是几千倍。
这就是为什么数据量越大，join的优势越明显。
坑一：在循环里用 += 拼接
这是最常见的性能陷阱。
result = ""
for item in items:
result += str(item) + "\n"
数据量小的时候（几百条），这个写法没问题。数据量大的时候（几万条以上），性能急剧下降。
正确的写法是用join：
result = "\n".join(str(item) for item in items)
或者先构建列表，再join：
parts = []
for item in items:
parts.append(str(item))
result = "\n".join(parts)
用列表推导式更简洁：
result = "\n".join(str(item) for item in items)
注意：join的参数可以是生成器表达式，不需要先创建完整列表。join内部会先遍历一遍生成器算出总长度，然后再遍历一遍填入内容。所以生成器表达式不会节省内存，但代码更简洁。
坑二：join 只能拼接字符串
join的参数必须是可迭代的字符串序列。如果里面包含非字符串，会报错：
nums = [1, 2, 3]
result = ", ".join(nums)
TypeError: sequence item 0: expected str instance, int found
需要先把每个元素转成字符串：
result = ", ".join(str(n) for n in nums)
或者用map：
result = ", ".join(map(str, nums))
坑三：join 的分隔符写反了
join的调用方式是分隔符.join(序列)，不是序列.join(分隔符)。
users = ["Alice", "Bob", "Charlie"]
# 正确
result = ", ".join(users) # "Alice, Bob, Charlie"
# 错误
result = users.join(", ") # AttributeError: 'list' object has no attribute 'join'
分隔符在前，序列在后。记住：用什么东西连接，就用什么东西调join。
坑四：用 + 拼接时忘了处理类型
+只能拼接字符串和字符串。如果一边是字符串，一边是数字，会报错：
name = "Alice"
age = 30
result = name + age
TypeError: can only concatenate str (not "int") to str
需要显式转换：
result = name + str(age)
或者用f-string：
result = f"{name}{age}"
f-string在Python 3.6+中可用，可读性更好，性能也不错。但如果是在循环里拼接大量字符串，join仍然是最优选择。
坑五：join 拼接非字符串序列
join也可以拼接元组、集合、生成器，只要里面的元素是字符串。
", ".join(("a", "b", "c")) # "a, b, c"
", ".join({"a", "b", "c"}) # 顺序不确定
", ".join(str(x) for x in range(3)) # "0, 1, 2"
但注意集合是无序的，拼接结果顺序不确定。
性能实测
我们来实际测一下不同数据量下+和join的差距。
import time
for n in [100, 1000, 10000, 100000]:
data = [str(i) for i in range(n)]
# 方式一：+
start = time.time()
result = ""
for item in data:
result += item + ","
t1 = time.time() - start
# 方式二：join
start = time.time()
result = ",".join(data)
t2 = time.time() - start
print(f"n={n}: + 耗时 {t1:.4f}s, join 耗时 {t2:.4f}s, 倍数 {t1/t2:.1f}x")
在我的机器上，结果大概是：
n=100: + 耗时 0.0001s, join 耗时 0.0000s, 倍数 3.2x
n=1000: + 耗时 0.0008s, join 耗时 0.0000s, 倍数 18.5x
n=10000: + 耗时 0.0752s, join 耗时 0.0003s, 倍数 250.7x
n=100000: + 耗时 7.5234s, join 耗时 0.0031s, 倍数 2427.0x
数据量越大，差距越夸张。n=100000时，+方式慢了2400多倍。
那 f-string 呢？
f-string是Python 3.6引入的字符串格式化方式，用起来很方便：
name = "Alice"
age = 30
result = f"{name} is {age} years old"
但f-string适合“少量变量拼接成一个字符串”的场景，不适合“大量字符串循环拼接”。
# 不适合：循环里用 f-string 拼接
result = ""
for user in users:
result += f"{user}, "
这本质上还是+=，还是O(n²)。正确的做法还是用join：
result = ", ".join(users)
f-string的优势在于可读性，不是性能。在需要拼接大量字符串时，join仍然是首选。
那 % 和 format 呢？
老式的%格式化和str.format()也能拼接字符串：
result = "%s, %s" % ("Alice", "Bob")
result = "{}, {}".format("Alice", "Bob")
但它们和f-string一样，适合少量变量的格式化，不适合大量字符串的循环拼接。
在循环里用%或format拼接，本质上还是创建新字符串，性能问题和+一样。
什么时候可以用 +？
+并不是一无是处。在以下场景，用+完全没问题：
拼接少量字符串（两三个）：
greeting = "Hello, " + name + "!"
字符串字面量拼接（编译期优化）：
s = "Hello, " "World" # 等价于 "Hello, World"
不关心性能的临时拼接：
msg = "错误: " + str(e)
只要不是在循环里拼接大量字符串，+的可读性其实更好。
join 的更多用法
join不仅可以拼接字符串列表，还可以拼接任何可迭代的字符串序列。
拼接多行文本：
lines = ["第一行", "第二行", "第三行"]
text = "\n".join(lines)
拼接路径：
parts = ["home", "user", "documents", "file.txt"]
path = "/".join(parts) # "home/user/documents/file.txt"
但路径拼接更推荐用os.path.join或pathlib，因为它们会处理不同操作系统的分隔符。
拼接CSV行：
rows = [["Alice", "30"], ["Bob", "25"]]
csv = "\n".join(",".join(row) for row in rows)
拼接SQL的IN子句：
ids = [1, 2, 3, 4, 5]
placeholders = ",".join("?" for _ in ids)
sql = f"SELECT * FROM users WHERE id IN ({placeholders})"
一个容易忽略的细节：join 的参数可以是任何可迭代对象
join不要求参数是列表。它可以是元组、生成器、range、字典的键，甚至是文件对象（按行迭代）。
", ".join(str(x) for x in range(5)) # "0, 1, 2, 3, 4"
", ".join({"a": 1, "b": 2}) # "a, b"，对键拼接
但注意：join需要遍历两次参数（第一次算长度，第二次填充），所以如果参数是生成器，它会被消耗掉。不过join内部会处理这个问题，你不需要担心。
回到小吴的故事
小吴最终的代码是这样的：
users = ["Alice", "Bob", "Charlie", "David"]
result = ", ".join(users)
print(result) # Alice, Bob, Charlie, David
末尾多余的逗号也没了，因为join只在元素之间插入分隔符，不会在末尾添加。
他后来在团队文档里写了一条：“循环里拼字符串，用join，别用+=。join是一次性分配内存，+=是每次都创建新字符串。数据量小的时候看不出来，数据量大了差距几千倍。+适合拼接两三个字符串，join适合拼接一堆字符串。”
这个区分看起来简单，但真到写代码的时候，很多人会下意识用+，因为在大多数语言里，字符串拼接就是+。Python的字符串不可变，所以+在循环里的代价特别高。
记住那个拼木板的比喻：+是每次加一块木板就把整张桌子拆了重做，join是先量好尺寸一次性拼好。你要拼一张大桌子，就用join；你只是把两块木板钉在一起，用+也无妨。
字符串拼接本身不难，难的是想清楚“这个拼接会不会在循环里执行”。想清楚了，join和+就不再是坑，而是两个各有适用场景的工具。
