测试中必须隔离文件系统，否则会导致测试间相互污染：一个测试写入的临时文件可能被另一个读到，或残留文件干扰后续运行，甚至误删生产路径文件；CI环境中尤为隐蔽。
为什么测试中要隔离文件系统
不隔离会导致测试间相互污染：一个测试写入的临时文件可能被另一个测试读到，或残留文件干扰后续运行；更严重的是，测试误删生产路径下的文件（比如把 /tmp 当成安全区，却实际覆盖了项目根目录的 config.json）。这类问题在 CI 环境里尤其隐蔽——本地跑得通，流水线却随机失败。
用 tempfile 模块创建真正隔离的临时路径tempfile 是 Python 标准库中专为该场景设计的模块，它能跨平台生成唯一路径，并自动绑定清理逻辑。关键不是“随便建个 /tmp/test_123”，而是让系统分配、由上下文管理生命周期。
- 直接调用
tempfile.mkdtemp() 返回一个新目录路径，但需手动 shutil.rmtree() 清理，容易遗漏
- 更稳妥的是用上下文管理器：
with tempfile.TemporaryDirectory() as tmpdir: —— 退出 with 块时自动删除整个目录，哪怕测试中途抛异常也生效
- 若只需单个临时文件，优先选
tempfile.NamedTemporaryFile(delete=False)，再手动 os.unlink()；避免用默认 delete=True，因为某些 Windows 场景下文件句柄未释放会导致 PermissionError
绕过真实磁盘：用 unittest.mock 替换 open 和 os 调用
当测试重点是逻辑而非 I/O 行为本身（比如验证配置解析函数是否正确提取字段），直接操作文件系统反而引入冗余依赖。
- 对
open 打补丁：@patch("builtins.open", mock_open(read_data='key: value'))，这样函数内调用 open() 实际不会触碰磁盘
- 对路径检查打补丁：
@patch("os.path.exists", return_value=True) 或 @patch("pathlib.Path.is_file", return_value=True)
- 注意：mock 的目标必须是被测代码导入的位置，不是定义位置。例如被测模块写了
import os，就得 patch "mymodule.os"，而不是 "os"
测试写入行为时，别信任 /tmp
很多开发者习惯把测试文件硬编码到 /tmp 或 ./test_data，这在并行测试或容器环境中会出问题：
- 多个 pytest 进程同时运行，都往
/tmp/myapp_test 写，内容互相覆盖
- Docker 容器里
/tmp 可能被挂载为 tmpfs，重启即丢，但测试期望文件持久存在
- CI runner 可能限制对
/tmp 的写权限，或配了只读文件系统
tempfile 模块创建真正隔离的临时路径tempfile 是 Python 标准库中专为该场景设计的模块，它能跨平台生成唯一路径，并自动绑定清理逻辑。关键不是“随便建个 /tmp/test_123”，而是让系统分配、由上下文管理生命周期。
- 直接调用
tempfile.mkdtemp()返回一个新目录路径，但需手动shutil.rmtree()清理，容易遗漏 - 更稳妥的是用上下文管理器：
with tempfile.TemporaryDirectory() as tmpdir:—— 退出with块时自动删除整个目录，哪怕测试中途抛异常也生效 - 若只需单个临时文件，优先选
tempfile.NamedTemporaryFile(delete=False)，再手动os.unlink()；避免用默认delete=True，因为某些 Windows 场景下文件句柄未释放会导致 PermissionError
绕过真实磁盘：用 unittest.mock 替换 open 和 os 调用
当测试重点是逻辑而非 I/O 行为本身（比如验证配置解析函数是否正确提取字段），直接操作文件系统反而引入冗余依赖。
- 对
open 打补丁：@patch("builtins.open", mock_open(read_data='key: value'))，这样函数内调用 open() 实际不会触碰磁盘
- 对路径检查打补丁：
@patch("os.path.exists", return_value=True) 或 @patch("pathlib.Path.is_file", return_value=True)
- 注意：mock 的目标必须是被测代码导入的位置，不是定义位置。例如被测模块写了
import os，就得 patch "mymodule.os"，而不是 "os"
测试写入行为时，别信任 /tmp
很多开发者习惯把测试文件硬编码到 /tmp 或 ./test_data，这在并行测试或容器环境中会出问题：
- 多个 pytest 进程同时运行，都往
/tmp/myapp_test 写，内容互相覆盖
- Docker 容器里
/tmp 可能被挂载为 tmpfs，重启即丢，但测试期望文件持久存在
- CI runner 可能限制对
/tmp 的写权限，或配了只读文件系统
open 打补丁：@patch("builtins.open", mock_open(read_data='key: value'))，这样函数内调用 open() 实际不会触碰磁盘@patch("os.path.exists", return_value=True) 或 @patch("pathlib.Path.is_file", return_value=True)
import os，就得 patch "mymodule.os"，而不是 "os"
/tmp
很多开发者习惯把测试文件硬编码到 /tmp 或 ./test_data，这在并行测试或容器环境中会出问题：
- 多个 pytest 进程同时运行，都往
/tmp/myapp_test写，内容互相覆盖 - Docker 容器里
/tmp可能被挂载为 tmpfs，重启即丢，但测试期望文件持久存在 - CI runner 可能限制对
/tmp的写权限，或配了只读文件系统
正确做法是：每个测试用例独占一个 TemporaryDirectory()，且路径不拼接固定字符串。如果必须复用某结构（如模拟整个 config 目录树），就在临时目录内用 os.makedirs() 构建，而不是假设某个全局路径可用。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
临时文件的清理时机和路径所有权，比内容本身更容易成为故障点。
