pytest本身不提供I/O缓存机制，所谓“缓存”是误解；真实I/O（文件、网络、数据库）导致测试变慢，应通过lru_cache、mock、tmp_path等手段绕过而非缓存。
pytest 本身不提供 I/O 缓存机制，所谓“pytest 的缓存机制”是常见误解 —— 它没有内置的磁盘/网络请求缓存能力，也不自动缓存文件读写或 HTTP 调用结果。 真正能起作用的是 Python 标准库的 functools.lru_cache、第三方库如 responses（HTTP）、pytest-mock（打桩），或手动控制 I/O 路径（如改用 io.BytesIO 或临时文件）。关键不是“让 pytest 缓存”，而是“在测试中绕过真实 I/O”。
为什么直接运行含真实 I/O 的测试会变慢
真实文件读写、数据库连接、HTTP 请求都受硬件/网络延迟影响，且每次运行都重复执行。pytest 默认每轮收集并执行所有测试函数，若每个测试都打开一次大文件或调用一次 API，累积延迟会迅速上升。
- 文件 I/O：尤其是
open(..., "r")读取 GB 级日志或 CSV，底层涉及系统调用 + 磁盘寻道 - 网络 I/O：未 mock 的
requests.get()会真实发包，超时设置不当可能卡住 30 秒 - 数据库 I/O：哪怕本地 SQLite，频繁
connect()+execute()仍比内存操作慢 2–3 个数量级
用 lru_cache 缓存纯函数的 I/O 结果（仅限可预测场景）
适用于：函数只依赖输入参数，且返回值稳定（比如解析固定配置文件、读取只读 JSON 模板）。注意它缓存的是函数返回值，不是文件句柄或连接对象。
import json
from functools import lru_cache
<p>@lru_cache(maxsize=1)
def load_config():
with open("config.json", "r") as f:
return json.load(f)
-
maxsize=1表示只缓存一次调用结果，适合全局只读配置 - 不能用于带副作用的函数（如写文件、修改全局状态）
- 若
config.json在测试期间被修改，缓存不会自动失效 —— 需手动调用load_config.cache_clear() - 不适用于参数动态变化的场景（如
load_user_data(user_id)，除非user_id极少且确定）
用 pytest-mock 或 unittest.mock.patch 替换 I/O 调用
这是最常用、最可靠的方式：把真实 I/O 替换为内存数据，彻底消除延迟。重点在于 patch 的目标路径必须准确（即被测代码中实际 import 和调用的位置）。
立即学习“Python免费学习笔记（深入）”；
def test_process_log_file():
# 假设被测函数内部写了：with open(path) as f: ...
from unittest.mock import patch
from io import StringIO
<pre class="brush:php;toolbar:false;">fake_content = "line1\nline2\nline3"
with patch("builtins.open", return_value=StringIO(fake_content)):
result = process_log_file("any_path.log")
assert result == 3
- Windows 下要 patch
builtins.open，Linux/macOS 同样适用；旧 Python 版本可能需用__builtin__.open - 若被测代码在模块
utils.py中写了import os; os.path.exists(...)，则需 patch"utils.os.path.exists"，而非"os.path.exists" - 避免 patch 过深（如 patch
io.open），容易漏掉其他调用路径 - 对 HTTP 请求，优先用
responses库注册 mock 响应，比 patchrequests.get更健壮
用 tmp_path fixture 快速生成可写临时文件
当测试必须“真写文件”（比如验证输出格式、编码是否正确），又不想污染项目目录或依赖固定路径时，tmp_path 是最佳选择 —— pytest 自动创建独立临时目录，测试结束自动清理。
def test_write_output_file(tmp_path):
output_file = tmp_path / "result.txt"
write_report(output_file) # 实际调用 open(..., "w")
assert output_file.read_text() == "OK\n"
-
tmp_path返回pathlib.Path对象，支持/拼接，无需手动处理路径分隔符 - 每个测试函数获得**全新**的
tmp_path，不存在跨测试干扰 - 不要在测试中硬编码
/tmp或./test_output—— 既不安全也不可重现 - 若需二进制内容，用
tmp_path / "data.bin"+.write_bytes(b"xxx")
真正难处理的不是“怎么缓存”，而是判断哪些 I/O 必须保留（比如验证磁盘一致性）、哪些可以安全替换（比如读取测试数据）。mock 过度会导致测试脱离真实环境，mock 不足又拖慢执行 —— 平衡点往往在具体业务逻辑的边界上，不在工具本身。
