Python并发写CSV无自动加锁，竞态导致随机截断或错行；csv.writer非线程/进程安全，'a'模式不保证原子追加；可靠方案仅两种：集中写（单点writer）或隔离写（分文件后合并）。
并发写入同一个CSV文件时，Python不会自动加锁，所有写操作直接落盘，谁最后写完谁赢——这不是“覆盖”，是竞态导致的随机截断或错行。
csv.writer 没有线程/进程安全机制
标准库 csv.writer 本质只是按行拼接字符串再调用 file.write()，它不维护内部缓冲锁，也不感知其他线程或进程是否正在操作同一文件句柄。即使你用 threading.Lock 包裹了 writer.writerow()，如果多个进程（比如用 multiprocessing）各自打开同一个文件路径，锁也完全无效——因为每个进程的文件对象是独立的，底层 OS 文件描述符互不感知。
- 现象：多进程调用
apply_async写同一 CSV，最终文件行数少于预期，且内容错乱（如两行合并成一行、字段偏移） - 根本原因：OS 层面对普通文件没有原子追加保证；
'a'模式只保证“每次write()调用从文件末尾开始”，但不保证“多个进程同时write()不会互相踩踏” - 验证方式：在写入前加
time.sleep(0.01)，错误率下降——说明是典型竞态，不是逻辑 bug
用 'a' 模式 ≠ 并发安全
很多人误以为把 'w' 换成 'a' 就能解决并发写问题，其实只是把“全量覆盖”换成“不可预测的碎片化写入”。'a' 只影响单次 open() 的起始位置，无法协调跨进程/线程的写入节奏。
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
-
with open('log.csv', 'a', newline='') as f:在每个进程中都成立，但 OS 调度可能让进程 A 刚定位到末尾、进程 B 就抢先写入，A 再写时就覆盖了 B 的部分字节 - 尤其在 Windows 上，
newline=''或编码不一致（如一个用utf-8，一个用gbk）会加剧错行，因为换行符解释不一致 - 别依赖
os.path.getsize()判断是否写完——它返回的是缓存大小，不是磁盘实际落盘状态
真正可靠的并发写方案只有两种
要么集中写，要么隔离写。没有第三条路。
立即学习“Python免费学习笔记（深入）”；
-
集中写（推荐）：所有数据发给一个专用写入进程（如用
asyncio.Queue+ 单独 writer task），其他 worker 只负责生产数据并 put 进队列。这样写入永远单点，csv.writer安全可用 -
隔离写（务实）：每个 worker 写自己的临时 CSV（如
f'worker_{pid}.csv'），全部完成后再用pandas.concat()或 shellcat *.csv > merged.csv合并。注意合并前需统一 header 和编码 - 绝对不要尝试用
fcntl.flock()（Linux/macOS）或mmap做手动同步——CSV 是文本格式，flock 只能锁整个文件，一锁就卡死吞吐，得不偿失
最常被忽略的点：你以为自己在“并发写 CSV”，其实是在用文本文件模拟数据库事务。CSV 本身就不支持并发写，强行做只会暴露底层 I/O 的裸露本质。要么换存储（SQLite / Parquet），要么改架构（单点 writer），别在 csv.writer 上堆补丁。
