io.StringIO可将str转为支持read/readline/seek的类文件对象，用于替代文件路径；BytesIO则处理bytes，二者不可混用，多次读取前须调用seek(0)重置位置。
用 io.StringIO 模拟文本文件对象
Python 中没有“把字符串当文件路径打开”这种操作，但可以用 io.StringIO 把字符串变成一个类文件对象，支持 .read()、.readline()、.seek() 等方法。它本质是内存中的缓冲区，不涉及磁盘 I/O。
常见错误是直接传字符串给原本期望 file 对象的函数（比如 pandas.read_csv() 或 json.load()），结果报 AttributeError: 'str' object has no attribute 'read' —— 这时候就得套一层 StringIO。
- 必须先
import io，不能跳过 - 传入的字符串要是
str类型（不是bytes），否则会报TypeError: initial_value must be str or None - 如果目标函数内部会多次调用
.read()（比如循环解析 CSV），记得在传入前用.seek(0)重置位置，否则第二次读就是空
示例：
import io import csv <p>data = "name,age\nAlice,30\nBob,25" f = io.StringIO(data) reader = csv.reader(f) for row in reader: print(row) # ['name', 'age'], ['Alice', '30'], ['Bob', '25']
用 io.BytesIO 处理二进制字符串或字节流
如果你手上的内容是 bytes（比如 HTTP 响应体、base64 解码后的数据、或需要传给 zipfile.ZipFile() 的压缩数据），就得用 io.BytesIO，它对应的是二进制模式。
立即学习“Python免费学习笔记（深入）”；
典型错误是混用：拿 BytesIO 去喂只接受文本模式的函数（如 json.load()），或者反过来用 StringIO 喂 gzip.GzipFile()，都会立刻抛异常。
-
BytesIO接收bytes，返回的对象调用.read()得到的仍是bytes - 很多标准库模块明确区分 text/binary 模式：
json.load()要StringIO，json.loads()才直接吃字符串；tarfile.open()的fileobj参数要BytesIO - 从网络或文件读出的原始数据，即使看起来像文本（如 UTF-8 编码的 JSON 字节串），只要类型是
bytes，就必须走BytesIO+ 解码逻辑，不能硬塞给StringIO
配合 pandas.read_* 等第三方库时的注意事项
像 pandas.read_csv()、pandas.read_excel()、xml.etree.ElementTree.parse() 这些函数，文档里写“filepath_or_buffer”，其中 “buffer” 就包括 StringIO 和 BytesIO，但具体支持哪一种，得看底层实现和格式要求。
-
pandas.read_csv()和.read_json()支持StringIO；.read_excel()只支持BytesIO（因为 Excel 是二进制格式） -
xml.etree.ElementTree.parse()接收StringIO，但要求字符串已解码为str；若原始是bytes，得先 decode 或改用BytesIO+xml.fromstring() - 某些库（如旧版
openpyxl）对 buffer 的 seek 行为敏感：如果传入的BytesIO位置不在开头，会读不到内容，务必加.seek(0)
别忘了 .seek(0) —— 最容易被忽略的一行代码
几乎所有基于流的处理都依赖当前位置。StringIO 和 BytesIO 初始化后位置都在开头，但一旦你调用了 .read(10) 或 .readline()，位置就移动了。后续再调用 .read() 就只能读到后面的内容，甚至为空。
尤其在调试时，你可能手动 .read() 了一次看内容，然后把同一个对象传给另一个函数，结果对方读不到任何东西——这时候八成是位置没重置。
- 只要对象会被多次读取（包括你自己 debug 读一次、函数内部再读一次），就在传入前加
f.seek(0) - 不要依赖“新建对象就一定安全”：如果函数内部保存了该对象并复用，下次调用仍可能出问题
- 对于只读一次的场景（如一次性传给
json.load()），可以不加，但加了也没坏处，建议养成习惯
