不能边循环边pd.concat，因其每次调用都复制全部已有数据，时间复杂度O(n²)，易致MemoryError、CPU 100%或运行骤慢；正确做法是先收集所有DataFrame到列表，再一次性concat。
为什么不能边循环边pd.concat
每次调用 pd.concat 都会复制全部已有数据，时间复杂度是 O(n²)。比如拼接 1000 个各含 10 行的 DataFrame，第 999 次 concat 实际要拷贝前 998 个 DataFrame 的全部行 —— 最终可能卡住或内存爆掉。
常见错误现象：MemoryError、CPU 占用长期 100%、运行时间从秒级跳到分钟级。
- 别在循环里写
result = pd.concat([result, df]) - 也别用
result = result.append(df)（已弃用且同样低效） - 哪怕 df 很小，累积效应也会快速显现
正确做法：先收集再一次性pd.concat
把所有待拼接的 DataFrame 丢进一个 Python 列表，等循环结束再调用一次 pd.concat。这是最直接、最可靠、兼容性最好的方案。
关键点：
立即学习“Python免费学习笔记（深入）”；
- 列表 append 是 O(1) 均摊操作，几乎无开销
-
pd.concat(..., ignore_index=True)能重置行索引，避免重复索引问题 - 如果原始 df 索引有意义（如时间序列对齐），则改用
ignore_index=False并确认索引类型一致
示例：
dfs = []
for item in data_source:
df = process_to_dataframe(item) # 每次返回一个小 DataFrame
dfs.append(df)
<h1>一次性拼接</h1><p>result = pd.concat(dfs, ignore_index=True)当内存吃紧时：考虑pd.concat的copy=False和分块
默认情况下 pd.concat 会尝试复用底层数组内存（如果可能），但 pandas 1.4+ 才真正支持 copy=False 参数来显式禁止深拷贝。老版本无效，别白加。
如果单次 pd.concat(dfs) 仍触发内存不足，说明列表 dfs 本身已占满内存（每个 df 的引用还在）。这时得换策略：
- 用生成器 + 分批 concat：每积累 50–100 个 df 就拼一次，再清空列表，append 到一个中间结果上
- 避免保留原始大对象：确保
process_to_dataframe(item)不偷偷缓存原始数据（比如没删掉item.raw_data） - 检查 dtypes：用
df.astype('category')或pd.Int64Dtype()替代 object / int64 可省大量内存
替代方案：pd.concat vs pd.DataFrame.from_records？
如果你的“小 DataFrame”其实都来自结构一致的字典/元组列表（比如 API 返回的 JSON 列表），那根本不用先转成一堆 DataFrame —— 直接攒成 list[dict] 或 list[tuple]，最后用 pd.DataFrame(records) 或 pd.DataFrame.from_records 构造一次。
这比“dict → DataFrame → list → concat”少两轮对象创建，更快更省内存。
- 适用场景：所有小单元字段名/顺序完全一致，无列缺失
- 不适用：每个 df 列不同、有动态列、需单独预处理逻辑
-
from_records比DataFrame(...)在大数据量下略快，但差异通常不大
真正容易被忽略的是：拼接前不检查列名是否对齐。列顺序不一致或个别 df 多/少一列，pd.concat 默认按列名对齐（join='outer'），结果会出现大量 NaN，而且很难一眼发现。建议加一句 assert all(df.columns.equals(dfs[0].columns) for df in dfs) 或至少 print(set.union(*[set(df.columns) for df in dfs])) 快速核对。
