流式读取大文件应避免一次性加载，优先用逐行迭代、分块读取（如pandas chunksize）、生成器管道；写入需原子操作或事务保障，异步i/o需谨慎评估实际收益。
流式读取大文件时内存爆掉怎么办
直接用 open().read() 或 pandas.read_csv() 加载几个 GB 的日志或 CSV，进程大概率被系统 kill。根本原因是默认把整份数据塞进内存，而流式处理的核心是「按需拉取、边读边算」。
- 用
open()配合for line in f:—— 每次只读一行，内存占用恒定，适合逐行解析（如日志过滤、字段提取） - 对 CSV，优先选
pandas.read_csv(chunksize=1000)，返回TextFileReader对象，每次get_chunk()拿一个 DataFrame，避免一次性加载 - 警惕
file.readlines()：它看似“逐行”，实则仍会把全部行加载进内存列表，和read()几乎等效
用 generator 实现自定义流式管道
内置的迭代方式不够灵活？比如要同时解压、解析 JSON、过滤字段、再写入数据库——这时 generator 是最轻量可控的流式抽象。
- 用
yield把每步逻辑拆成惰性函数，例如：def parse_json_lines(f):里循环yield json.loads(line) - 管道组合靠生成器表达式或
itertools.chain，而不是拼接中间 list；否则就退化成内存全载 - 注意 generator 只能遍历一次，如果后续需要多次消费（比如统计 + 写出），要么重跑 pipeline，要么缓存到磁盘/数据库，别试图
list(gen)
异步流式处理（aiofiles + async for）踩坑点
当 I/O 成瓶颈（比如从 S3 或网络流持续拉数据），同步流式仍可能卡住主线程。async 方案可行，但 Python 的 async 文件生态不成熟，容易掉进陷阱。
华友协同办公自动化OA系统
下载
华友协同办公管理系统(华友OA)，基于微软最新的.net 2.0平台和SQL Server数据库，集成强大的Ajax技术，采用多层分布式架构，实现统一办公平台，功能强大、价格便宜，是适用于企事业单位的通用型网络协同办公系统。 系统秉承协同办公的思想，集成即时通讯、日记管理、通知管理、邮件管理、新闻、考勤管理、短信管理、个人文件柜、日程安排、工作计划、工作日清、通讯录、公文流转、论坛、在线调查、
-
aiofiles不支持async for line in f—— 它没有实现__aiter__，必须手动await f.readline()循环 - 别在 async 函数里混用
time.sleep()或阻塞调用（如json.loads()大字符串），会拖垮整个 event loop - 真正高吞吐场景下，async 文件 I/O 性能未必比多线程 + 同步流好；先压测，别预设“async 一定更快”
流式写入时如何保证数据不丢
边读边写，程序崩溃或断电，最后几条数据就没了。这不是 Python 特有，而是流式系统的共性难题。
立即学习“Python免费学习笔记（深入）”；
- 写文件时禁用缓冲：
open(..., buffering=1)（行缓冲）或buffering=0（仅限二进制模式），但会明显降低吞吐 - 更稳妥的做法是「先写临时文件 + 原子重命名」：用
tempfile.NamedTemporaryFile(delete=False)，写完os.replace(tmp_path, final_path) - 如果目标是 Kafka 或数据库，必须启用事务或至少确认机制（如
producer.send(...).get(timeout=10)），不能只调用 send 就不管
流式不是加个 for 循环就万事大吉；关键在控制数据生命周期——什么时候申请、什么时候释放、异常时谁负责清理。这些边界在小数据上不显眼，一到生产环境就立刻暴露。
