POSIX 文件 I/O 不支持并发写入，即使使用 'a' 模式也会因各线程独立文件偏移量导致数据交错；必须用共享 threading.Lock 串行化 open→write→close 全流程。
直接多线程写同一个文件出现数据交错，不是代码写错了，而是 POSIX 文件 I/O 模型本身就不支持并发写入——哪怕都用 'a' 追加模式。
为什么 open(..., 'a') 也不能避免交错
追加模式只保证每次 write() 系统调用从文件末尾开始写，但“末尾”是动态的：多个线程各自调用 open() 后，会拿到独立的文件描述符（file descriptor），每个都有自己的内核维护的文件偏移量。当线程 A 刚把偏移量设到末尾、准备写入时，线程 B 已经抢先写了一段并推进了偏移量，A 就会覆写 B 刚写的内容，或与 B 的写入在缓冲区里交叉拼接。
- 现象：一行日志被切成两段，比如
"user_id=123, status=ok"变成"user_id=123, stat"和"us=ok" - 原因：
f.write()不是原子操作；底层write(2)系统调用可能被中断、拆分成多次，且各线程的缓冲区和系统调用时机不可控 - 关键点：这不是 Python 实现的问题，C 标准库、Java、Go 在同样场景下也会出错
threading.Lock 锁不住文件，除非锁对地方
常见错误是只锁 f.write()，却放任多个线程各自 open()。这样锁的是“写动作”，不是“写入权”——每个线程早已拿到自己的文件句柄，锁再严也拦不住它们往同一块磁盘位置乱写。
- 必须共享一把
threading.Lock实例（不能在线程函数里lock = threading.Lock()） - 锁的作用域必须覆盖整个 I/O 生命周期：
open()→f.write()→f.close() - 避免用
print(..., file=f)，它内部调用write()+flush()，步骤不可控，容易漏锁
异步写文件用 aiofiles 而不是 aiofile
aiofile 底层调度不一致，尤其在 Windows 或某些文件系统上，协程间共享的文件偏移状态可能错乱；而 aiofiles 是基于 loop.run_in_executor() 把阻塞 I/O 交给线程池执行，行为更接近同步 open，天然规避了偏移竞争。
立即学习“Python免费学习笔记（深入）”；
- 必须共用一把
asyncio.Lock()，而不是为每个文件建一个锁——否则question_writer.write()和answer_writer.write()仍会并发争抢同一文件系统的写位置 -
aiofiles.open(..., 'w')默认行缓冲，配合await f.write(...)+await f.flush()可保障单行完整性 - 不用手动
fsync()；aiofiles在close()时自动 flush，频繁fsync()反而拖慢吞吐
真正难的不是加锁，而是意识到：文件对象不是线程安全的载体，操作系统也不认为“同时写一个文件”是个合理需求。所有看似绕开锁的技巧（比如用临时文件+rename），最终都要面对原子性边界——要么靠锁串行化，要么靠队列把写操作收归单一线程。
