readlines() 更危险，因它将全部行加载为带换行符的列表，内存开销远超 read()；安全做法是用 for line in f 迭代读取。
读大文件时 read() 和 readlines() 哪个更危险
直接说结论：readlines() 在多数场景下比 read() 更容易爆内存，尤其当行很长或行数极多时。它会把每行末尾的换行符保留并全部加载进内存，生成一个巨大的 list —— 而 read() 至少还能靠切片或正则分块处理。
常见错误现象：程序在处理几百 MB 的日志文件时突然卡死，MemoryError 或被系统 OOM killer 杀掉；用 top 或 htop 观察发现 Python 进程 RSS 内存飙升到几 GB。
-
readlines()本质是list+ 每行字符串对象，每个字符串有额外开销（如引用计数、哈希缓存），小文件无感，大文件代价翻倍 -
read()返回单个str，没有列表结构开销，但如果你接着.split('\n')，其实又回到了readlines()的问题上 - 真正安全的做法是用迭代器：
for line in f:—— 它底层调用__next__()，每次只读一行，不预加载
正则 re.findall() 处理长文本的隐性开销
不是正则本身慢，而是 re.findall() 默认返回所有匹配结果的 list，一旦匹配项成千上万（比如从 HTML 中提取所有 <a href=...>），这个 list 就成了内存黑洞。
使用场景：清洗爬虫抓取的网页正文、解析带大量重复模式的日志段落。
立即学习“Python免费学习笔记（深入）”；
- 如果只需要遍历结果，改用
re.finditer()，它返回生成器，每次 yield 一个Match对象 - 注意
re.compile()缓存：高频调用时务必提前编译，否则每次findall()都重新解析正则，CPU 和内存双浪费 - 避免写
re.findall(r'.*', text)这类贪婪通配——它可能把整个文本塞进一个匹配组，再复制一份作为返回值
str.split() vs str.partition() 的性能分水岭
当你只关心第一次分割位置（比如解析 "key=value"），partition() 比 split('=', 1) 快且省内存，因为前者不构造列表，后者仍要分配一个两元素 list。
参数差异明显：partition() 固定返回三元组 (before, sep, after)，而 split(sep, maxsplit=1) 返回 list，哪怕你只切一刀。
- 实测：在 10MB 字符串中做单次分割，
partition()比split(..., 1)快 2–3 倍，内存分配少 90%+ - 如果后续还要对结果做索引访问（如
parts[0]），partition()的元组解包更直接：key, _, value = s.partition('=') - 但注意：
partition()找不到分隔符时返回(s, '', '')，而split()会返回[s]—— 逻辑处理时别漏掉这个差异
用 io.StringIO 模拟文件时的缓冲陷阱
StringIO 看似轻量，但它内部用的是可变字符串缓冲（类似 list 存字符），频繁 write() 小片段会导致多次内存重分配，性能断崖式下跌。
典型场景：拼接大量模板字符串、构建 CSV 内容、日志聚合后统一写入。
- 避免循环里反复
sio.write(part)，改用''.join(parts)预组装，再一次性write() - 如果必须流式写入，考虑初始化时指定足够大的
initial_value，减少扩容次数 - 和真实文件句柄不同，
StringIO不受系统页缓存影响，但它的内存占用完全暴露给 Python GC —— 大对象不及时del或脱离作用域，会拖慢回收
真正麻烦的从来不是“怎么写”，而是“哪部分数据该留在内存里”。比如一次处理 1GB 日志，你得想清楚：哪些字段必须全量驻留（如去重 ID 集合），哪些可以即用即弃（如中间匹配结果）。没想清这点，光换函数名没用。
