Bind Mount 通过挂载宿主机静态桩文件实现数据传递，适用于 JSON 配置、Mock 响应、数据库快照等预置场景；需版本控制、只读挂载，并配合脚本切换桩集，动态模拟则需结合 HTTP stub 服务。
Bind Mount 本身不“注入”测试桩，而是把宿主机上已准备好的桩数据文件或目录，直接挂载进测试容器——相当于用文件系统做数据传递。它适合那些不需要运行时动态生成、结构稳定、可预先写死的测试桩（如 JSON 配置、Mock API 响应体、固定数据库 dump 文件等）。
提前准备好桩数据文件
在项目根目录或 tests/fixtures/ 下创建真实可用的桩内容：
-
tests/fixtures/mock_api_responses/user_404.json→ 内容：{"error": "not found", "code": 404} -
tests/fixtures/config/test.env→ 模拟不同环境变量 -
tests/fixtures/db/dump.sql→ 预置干净的测试数据库快照
这些文件是静态的、版本可控的，和代码一起提交，确保所有开发者与 CI 环境使用同一套桩数据。
用 -v 挂载到容器指定路径
启动测试容器时，把本地桩目录映射过去，被测服务读取时就自然拿到 mock 数据：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- API 测试：挂载
fixtures/mock_api_responses到容器内/app/stubs/，服务代码通过ReadFile("/app/stubs/user_404.json")加载响应 - 配置测试：挂载
fixtures/config/test.env到/etc/app/config.env，应用启动时按约定路径加载 - 数据库测试：挂载
fixtures/db/dump.sql到容器内固定路径，配合初始化脚本自动导入
配合脚本实现一键切换桩集
不同测试场景可能需要不同桩组合（如网络异常 vs 正常流程），可用 shell 脚本管理：
- 定义多个桩子目录：
fixtures/stubs/v1_ok/、fixtures/stubs/v2_timeout/ - 测试命令中用变量控制挂载路径：
docker run -v $(pwd)/fixtures/stubs/v2_timeout:/app/stubs ... - CI 中通过环境变量选择：
STUB_SET=v2_timeout make test
避免硬编码路径，提升可复用性。
注意隔离性与清理
Bind Mount 是双向实时同步的，测试过程若意外修改了桩文件，会影响后续测试：
- 推荐将桩目录设为只读：
docker run -v $(pwd)/fixtures:/app/stubs:ro ... - 不要让被测程序有写权限，防止污染源数据
- CI 环境中建议每次拉取干净 Git 工作区，避免本地残留改动干扰
真正需要动态行为模拟（比如根据请求参数返回不同响应）时，Bind Mount 不够用，应搭配轻量 HTTP stub 服务（如 WireMock、Mockoon）或改用接口 mock + 依赖注入。
