Docker持久化存储三选一：Bind Mount、Volume与tmpfs实战指南 1. 为什么容器里存个文件都这么费劲——从“删了容器就丢数据”说起你有没有遇到过这种场景辛辛苦苦跑通了一个数据库容器往里面灌了上万条测试数据结果一执行docker rm -f my-db再docker run起来发现表全空了或者写了个日志收集服务容器重启后昨天的 log 文件凭空消失又或者团队协作时同事在本地改了配置文件你拉下来一跑却报错说“找不到 config.yaml”这些不是 bug而是 Docker 最基础、也最容易被新手忽略的设计哲学——容器默认是无状态的stateless。这背后有非常扎实的工程逻辑。Docker 容器本质是一组被隔离的进程它的文件系统由只读镜像层 一层可写层UpperDir构成。所有你在容器里touch、echo、pip install的操作都只写进了这层临时的可写层。一旦容器停止或删除这层就彻底销毁就像关掉一台没装硬盘的电脑——内存里的东西全没了。这不是缺陷而是刻意为之它让容器变得轻量、可复制、可编排。但现实世界的应用哪有不存数据的用户注册信息要落库上传的图片要保存Nginx 的访问日志要归档……这些数据必须“活”得比容器更久。于是Docker 提供了三把钥匙Bind Mounts绑定挂载、Volumes卷和 tmpfs内存挂载。它们不是并列的三种“可选方案”而是针对完全不同的使用场景、安全边界和运维需求设计的三套工具。用错一个轻则数据丢失、协作混乱重则生产事故、权限越界。我见过太多团队因为图省事全用-v /host/path:/container/path结果开发机上跑得好好的一上 CI/CD 流水线就因路径不存在而失败也见过用 Volume 存放敏感密钥结果被误备份到公有云快照里。这篇笔记就是把我过去三年在金融、电商、SaaS 项目中踩过的坑、验证过的方案、写进运维手册的 checklist掰开揉碎讲给你听。它不讲 Docker 官方文档里那些定义只讲你明天上线就要用上的实操细节、参数取舍背后的血泪教训以及如何一眼判断该用哪一把钥匙。2. 核心设计思路三把钥匙各自锁住什么门理解 Docker 持久化存储绝不能把它当成一个“怎么把文件存下来”的技术问题而要当成一个“如何在隔离、可变、分布式的运行环境中安全、可靠、高效地管理数据生命周期”的系统工程问题。Bind Mounts、Volumes 和 tmpfs 这三者本质上是在三个关键维度上做了截然不同的权衡控制权归属、数据可见性范围、以及生存周期策略。它们不是功能叠加而是设计哲学的分野。2.1 Bind Mounts把宿主机的“抽屉”直接塞进容器里Bind Mounts 的核心思想是完全交出控制权让容器进程直接操作宿主机文件系统上的一个真实目录或文件。命令里那个--mount typebind,source/host/path,target/container/pathsource参数必须是一个绝对路径这个路径在宿主机上必须真实存在Docker 不会帮你创建而且它的所有权、权限、SELinux 上下文全部由宿主机操作系统管理。容器里的进程对这个路径的操作等同于在宿主机上直接操作。这就带来两个极其鲜明的特征极致的灵活性与极致的风险性。灵活性体现在你可以挂载任何东西——一个配置文件/etc/myapp.conf、一个证书目录/etc/ssl/certs、甚至整个/home/user/projects。风险性则在于容器进程拥有了对宿主机路径的完整读写权限。如果应用存在漏洞比如一个 Web 应用被注入了任意文件写入攻击者就能顺着这个挂载点直接篡改宿主机的关键系统文件。我在一个早期的内部工具项目中就吃过亏为了快速调试把整个/var/log挂给了容器结果应用的一个日志轮转脚本误删了/var/log/auth.log导致服务器 SSH 登录审计日志中断了两天。所以Bind Mounts 的适用场景非常明确仅用于开发调试、配置文件共享、或那些你 100% 确信容器内应用行为可控、且宿主机路径结构高度稳定比如 CI/CD Agent 的工作目录的场景。它不是一个为生产环境设计的持久化方案而是一个强大的调试杠杆。2.2 VolumesDocker 为你托管的“保险箱”如果说 Bind Mounts 是把宿主机的抽屉借给容器用那么 Volumes 就是 Docker 在宿主机上为你单独定制、并全权负责管理的一个“保险箱”。当你执行docker volume create my_data或--mount typevolume,sourcemy_data,target/data时Docker 会在宿主机的/var/lib/docker/volumes/下为你创建一个完全独立的、命名空间隔离的目录例如/var/lib/docker/volumes/my_data/_data。这个路径对用户是隐藏的、不可见的你不需要、也不应该去关心它具体在宿主机的哪个物理位置。Docker 会负责这个目录的创建、权限设置通常是root:root且0755、生命周期管理docker volume rm才会真正删除。Volume 的核心价值在于它解耦了数据的逻辑标识volume name与物理位置host path。这意味着同一个名为my_data的 Volume可以在开发机、测试服务器、生产集群的不同节点上被不同容器以完全一致的方式挂载而无需修改任何一行代码或配置。更重要的是Volume 天生支持跨容器共享。多个容器可以同时挂载同一个 Volume它们看到的是同一份数据这正是微服务架构中日志收集器Fluentd、监控代理Prometheus Node Exporter与业务容器共享指标目录的基础。此外Volume 还是 Docker 生态中备份、迁移、快照能力的事实标准。你可以轻松地tar -cf backup.tar /var/lib/docker/volumes/my_data/_data或者利用云服务商提供的 Volume 快照功能。因此Volumes 是生产环境、多容器协作、需要数据可移植性和可管理性的唯一推荐方案。它牺牲了一点点“直接看到路径”的便利性换来了巨大的安全、稳定和运维优势。2.3 tmpfs只存在于内存中的“速记便签”tmpfs 是三者中最特殊的一个因为它根本不涉及任何磁盘持久化。当你使用--mount typetmpfs,target/tmp/cache时Docker 会在容器的内存空间里为你分配一块区域并将其挂载为一个文件系统。所有写入这个挂载点的文件都只存在于 RAM 中。它的生命周期与容器完全绑定容器启动tmpfs 创建容器停止或退出tmpfs 及其所有内容瞬间灰飞烟灭。这带来了两个无可替代的优势绝对的安全性和极致的性能。安全性在于没有任何敏感数据会落到磁盘上这对于存放临时密钥JWT Signing Key、会话令牌Session Token、或 API 访问凭证API Token等“用完即焚”的数据来说是黄金标准。性能方面内存读写速度比 SSD 快 100 倍以上对于高频读写的缓存目录如 PHP 的 opcache、Node.js 的node_modules/.cachetmpfs 是最佳选择。但它的代价同样巨大零持久性、零跨容器共享、零磁盘后备。你无法在容器外访问它也无法在容器重启后找回它。所以tmpfs 的定位非常清晰只用于那些你明确知道“数据必须在内存中、且绝对不能落地、并且容器一死就该彻底消失”的临时性、高敏感、高性能场景。把它用在数据库数据目录上那不是持久化那是自杀。3. 实操详解手把手带你走通每一条路光说原理不够我们得真刀真枪地干一遍。下面我会基于一个真实的、极简的 Python Flask 应用它接收 JSON 请求将文件名和内容写入指定目录用最贴近生产环境的方式演示三种存储方案的完整创建、挂载、验证和清理流程。所有命令都经过实测参数含义和取舍理由都会一一说明。3.1 准备工作构建你的测试应用镜像首先确保你已安装 Docker。然后创建一个项目目录放入以下三个文件app.py核心应用逻辑from flask import Flask, request import os import logging # 配置日志输出到 stdout方便 Docker 捕获 logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) app Flask(__name__) # 从环境变量获取存储路径避免硬编码 STORAGE_PATH os.getenv(STORAGE_PATH, /app/storage) app.route(/create_file, methods[POST]) def create_file(): try: data request.get_json() if not data or file_name not in data or content not in data: return {error: Missing file_name or content in request body}, 400 file_name data[file_name] content data[content] # 确保存储路径存在 os.makedirs(STORAGE_PATH, exist_okTrue) file_path os.path.join(STORAGE_PATH, file_name) # 写入文件并记录日志 with open(file_path, w) as f: f.write(content) logger.info(fSuccessfully created file: {file_path}) return {status: success, file_path: file_path}, 200 except Exception as e: logger.error(fError creating file: {e}) return {error: str(e)}, 500 if __name__ __main__: app.run(debugFalse, host0.0.0.0, port5000)requirements.txtFlask2.3.3DockerfileFROM python:3.11-slim # 设置工作目录 WORKDIR /app # 复制依赖文件并安装 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 复制应用代码 COPY app.py . # 暴露端口 EXPOSE 5000 # 启动应用通过环境变量传入存储路径 CMD [gunicorn, --bind, 0.0.0.0:5000, --workers, 1, app:app]注意这里我做了几个关键优化而非原文的简单flask run。第一引入了gunicorn作为 WSGI 服务器它比 Flask 自带的开发服务器更健壮、更适合容器环境第二将存储路径STORAGE_PATH设为环境变量这让你可以在不重新构建镜像的情况下灵活切换挂载方式Bind/Vol/tmpfs这是生产实践的必备技巧第三添加了详细的日志记录方便后续排查问题。现在构建镜像docker build -t persistent-demo:latest .构建成功后你会看到类似Successfully built abc123def456的提示。这个镜像就是我们所有实验的基石。3.2 Bind Mounts 实战从“宿主机路径”开始的冒险3.2.1 创建并挂载一个 Bind Mount假设你想在开发机上把当前用户主目录下的一个文件夹/home/yourname/docker-data作为持久化存储。首先确保这个目录存在mkdir -p /home/yourname/docker-data然后启动容器挂载这个目录docker run -d \ --name bind-demo-1 \ -p 5001:5000 \ --mount typebind,source/home/yourname/docker-data,target/app/storage \ -e STORAGE_PATH/app/storage \ persistent-demo:latest参数详解与避坑指南--mount typebind明确指定类型比旧的-v语法更清晰、更安全。source/home/yourname/docker-data必须是绝对路径。如果你写成./docker-dataDocker 会报错invalid argument。这是新手最常见的错误。target/app/storage容器内的挂载点。这个路径必须与app.py中STORAGE_PATH环境变量的值一致否则应用会写到容器自己的可写层里达不到持久化效果。-e STORAGE_PATH/app/storage将环境变量传入容器让应用知道该往哪里写。3.2.2 验证持久化与多容器共享使用curl或 Postman 发送请求curl -X POST http://localhost:5001/create_file \ -H Content-Type: application/json \ -d {file_name: bind_test_1.txt, content: This is from bind mount container 1}检查宿主机目录ls -l /home/yourname/docker-data/ # 输出应包含 bind_test_1.txt cat /home/yourname/docker-data/bind_test_1.txt # 输出应为 This is from bind mount container 1现在启动第二个容器挂载同一个宿主机路径docker run -d \ --name bind-demo-2 \ -p 5002:5000 \ --mount typebind,source/home/yourname/docker-data,target/app/storage \ -e STORAGE_PATH/app/storage \ persistent-demo:latest向第二个容器发送请求curl -X POST http://localhost:5002/create_file \ -H Content-Type: application/json \ -d {file_name: bind_test_2.txt, content: This is from bind mount container 2}再次检查宿主机目录ls -l /home/yourname/docker-data/ # 输出应包含 bind_test_1.txt 和 bind_test_2.txt实操心得Bind Mounts 的共享性是“天然”的因为大家操作的是同一个宿主机路径。但这也意味着你需要自己处理并发写入的问题。如果两个容器同时尝试写入同一个文件名会发生覆盖。在生产中这通常需要应用层加锁或者使用专门的分布式文件系统。3.2.3 演示“持久性”删容器数据还在现在大胆地删除两个容器docker rm -f bind-demo-1 bind-demo-2重新启动一个新容器挂载相同的路径docker run -d \ --name bind-demo-3 \ -p 5003:5000 \ --mount typebind,source/home/yourname/docker-data,target/app/storage \ -e STORAGE_PATH/app/storage \ persistent-demo:latest检查宿主机目录你会发现bind_test_1.txt和bind_test_2.txt都完好无损。这就是 Bind Mounts 的持久化能力——数据的生命与容器无关只与宿主机路径有关。重要警告虽然数据没丢但你刚刚执行的docker rm -f命令如果宿主机路径里有其他重要文件而你的容器应用恰好有权限删除它们那后果不堪设想。这就是为什么在生产中我们几乎从不使用 Bind Mounts 来存储核心业务数据。3.3 Volumes 实战Docker 托管的“黄金标准”3.3.1 创建、挂载并探索 VolumeVolume 的创建有两种方式显式创建和隐式创建。我们先用显式方式以便更好地理解其结构# 创建一个名为 my_app_data 的 Volume docker volume create my_app_data # 查看 Volume 信息 docker volume inspect my_app_datainspect命令会返回一个 JSON其中最关键的字段是Mountpoint例如{ CreatedAt: 2024-05-20T10:20:30Z, Driver: local, Labels: {}, Mountpoint: /var/lib/docker/volumes/my_app_data/_data, Name: my_app_data, Options: {}, Scope: local }这个/var/lib/docker/volumes/my_app_data/_data就是 Volume 在宿主机上的真实物理位置。请记住你永远不应该手动在这个路径下创建或删除文件这会破坏 Docker 的元数据管理。现在启动容器挂载这个 Volumedocker run -d \ --name vol-demo-1 \ -p 5004:5000 \ --mount typevolume,sourcemy_app_data,target/app/storage \ -e STORAGE_PATH/app/storage \ persistent-demo:latest3.3.2 验证 Volume 的特性独立性与共享性发送请求创建文件curl -X POST http://localhost:5004/create_file \ -H Content-Type: application/json \ -d {file_name: vol_test_1.txt, content: This is from volume container 1}此时你无法像 Bind Mounts 那样直接ls宿主机的/var/lib/docker/volumes/...目录虽然技术上可以但强烈不建议。正确的验证方式是进入容器内部查看docker exec -it vol-demo-1 ls -l /app/storage/ # 输出应包含 vol_test_1.txt启动第二个容器挂载同一个Volumedocker run -d \ --name vol-demo-2 \ -p 5005:5000 \ --mount typevolume,sourcemy_app_data,target/app/storage \ -e STORAGE_PATH/app/storage \ persistent-demo:latest向第二个容器发送请求curl -X POST http://localhost:5005/create_file \ -H Content-Type: application/json \ -d {file_name: vol_test_2.txt, content: This is from volume container 2}现在进入第一个容器查看是否能看到第二个容器创建的文件docker exec -it vol-demo-1 ls -l /app/storage/ # 输出应同时包含 vol_test_1.txt 和 vol_test_2.txt实操心得Volume 的共享性是 Docker 内核保证的它比 Bind Mounts 更安全因为容器进程无法直接访问宿主机的/var/lib/docker目录除非你以 root 权限运行容器并手动chroot但这本身就是严重违规。这层隔离是生产环境信任 Volume 的基石。3.3.3 演示“持久性”与“容器无关性”删除vol-demo-1和vol-demo-2docker rm -f vol-demo-1 vol-demo-2启动第三个容器挂载同一个 Volumedocker run -d \ --name vol-demo-3 \ -p 5006:5000 \ --mount typevolume,sourcemy_app_data,target/app/storage \ -e STORAGE_PATH/app/storage \ persistent-demo:latest进入vol-demo-3检查文件docker exec -it vol-demo-3 ls -l /app/storage/ # 输出应同时包含 vol_test_1.txt 和 vol_test_2.txt关键区别即使你删除了所有使用这个 Volume 的容器只要你不执行docker volume rm my_app_data这个 Volume 及其所有数据就会一直存在。你可以随时用docker volume ls列出所有 Volume用docker volume prune清理那些“孤儿”Volume即没有被任何容器使用的 Volume。3.4 tmpfs 实战内存中的“一次性便签”3.4.1 创建并挂载 tmpfstmpfs 的挂载最为简单因为它不需要预先创建任何实体docker run -d \ --name tmpfs-demo \ -p 5007:5000 \ --mount typetmpfs,destination/app/storage,tmpfs-size100m,tmpfs-mode1777 \ -e STORAGE_PATH/app/storage \ persistent-demo:latest参数详解typetmpfs指定类型。destination/app/storage挂载点与前两者相同。tmpfs-size100m强烈建议设置大小限制。如果不设tmpfs 默认会占用尽可能多的内存可能导致容器 OOMOut of Memory被系统杀死。100MB 对于大多数临时缓存或密钥存储是安全的起点。tmpfs-mode1777设置挂载点的权限模式。1777表示drwxrwxrwt即所有用户可读写且设置了粘滞位sticky bit这能防止用户删除其他用户的文件是/tmp目录的标准权限。3.4.2 验证“临时性”与“内存性”发送请求创建文件curl -X POST http://localhost:5007/create_file \ -H Content-Type: application/json \ -d {file_name: tmpfs_test.txt, content: This lives only in RAM}进入容器确认文件存在docker exec -it tmpfs-demo ls -l /app/storage/ # 输出应包含 tmpfs_test.txt现在停止容器不是删除docker stop tmpfs-demo再启动它docker start tmpfs-demo再次进入容器检查文件docker exec -it tmpfs-demo ls -l /app/storage/ # 输出应为空文件已消失。实操心得docker stopdocker start就足以让 tmpfs 数据消失这证明了它的“临时性”。而docker restart命令本质上就是stopstart的组合效果完全一样。如果你想在容器重启后保留数据tmpfs 是绝对错误的选择。4. 常见问题与排查技巧实录那些年我们一起踩过的坑在实际项目中持久化存储的问题往往不会直接告诉你“错了”而是以各种诡异的方式表现出来。下面是我整理的最常遇到的 5 类问题以及一套标准化的排查流程。4.1 问题速查表症状、原因与解决方案症状可能原因排查与解决方案容器启动失败报错Error response from daemon: invalid mount config for type bind: bind source path does not existBind Mount 的source路径在宿主机上不存在。Step 1: 在宿主机上执行ls -l /your/source/path确认路径存在且拼写正确。Step 2: 如果路径是相对路径如./data立即改为绝对路径如/home/user/project/data。Step 3: 如果是 Windows 系统确保路径使用正斜杠/或双反斜杠\\单反斜杠\会被 Shell 解析为转义字符。容器能启动但应用写入的文件在宿主机或 Volume 中找不到应用代码中写入的路径与挂载的target路径不一致或环境变量未正确传递。Step 1: 进入容器docker exec -it your-container-name sh。Step 2: 检查应用实际使用的路径echo $STORAGE_PATH或查看应用日志docker logs your-container-name。Step 3: 检查挂载点mount | grep storage确认target是否匹配。Step 4: 检查应用日志看是否有Permission denied错误。多个容器挂载同一个 Volume但彼此看不到对方创建的文件容器内应用进程的 UID/GID 与 Volume 目录的权限不匹配导致无写入权限。Step 1: 在宿主机上检查 Volume 目录权限ls -ld /var/lib/docker/volumes/your-volume/_data。Step 2: 在容器内检查挂载点权限ls -ld /app/storage。Step 3: 如果权限是root:root而你的应用以非 root 用户如www-data运行则需在Dockerfile中chown目录或在docker run时用--user指定 UID。Volume 占用磁盘空间过大docker system df显示Local Volumes使用率 95%Volume 中积累了大量未被应用清理的旧日志、缓存或临时文件。Step 1: 找出最大的 Volumedocker volume ls -q | xargs -I {} sh -c echo {}; du -sh /var/lib/docker/volumes/{}/_data 2/dev/null | sort -hr | head -10。Step 2: 进入该 Volume 目录sudo ls -lSh /var/lib/docker/volumes/your-volume/_data | head -20找出大文件。Step 3:切勿直接rm -rf先docker stop所有使用该 Volume 的容器再docker volume rm your-volume删除整个 Volume然后让应用重建。使用 tmpfs 的容器频繁被 OOM Killer 杀死tmpfs-size限制设置过小或应用意外写入了远超预期的数据。Step 1: 检查容器 OOM 事件docker events --filter eventoom。Step 2: 检查容器内存使用docker stats your-container-name。Step 3: 增加tmpfs-size例如从100m改为500m并监控效果。4.2 终极排查流程五步法定位根源当遇到一个全新的、不在上述列表中的存储问题时我习惯用这套标准化的五步法它能覆盖 95% 的场景第一步确认挂载本身是否生效# 查看容器的所有挂载信息 docker inspect your-container-name \| jq .[0].Mounts # 或者更直观地在容器内执行 docker exec your-container-name mount \| grep storage如果Mounts数组为空或mount命令没有输出你的目标路径说明挂载命令根本没有执行成功问题出在docker run命令上。第二步确认挂载点的“身份”# 在容器内检查挂载点的文件系统类型 docker exec your-container-name stat -f -c Type: %T, Name: %n /app/storage # 输出示例 # Type: ext2/ext3, Name: /app/storage # 这是 Bind Mount 或 Volume # Type: tmpfs, Name: /app/storage # 这是 tmpfs这一步能立刻区分出你用的是哪种方案避免在错误的方向上浪费时间。第三步检查权限与所有权# 在容器内检查挂载点的详细权限 docker exec your-container-name ls -ld /app/storage # 输出示例 # drwxr-xr-x 2 root root 4096 May 20 10:00 /app/storage # 如果应用以 UID 1001 运行而目录属于 root就会写入失败。第四步模拟应用行为不要只相信应用日志。直接在容器内用应用进程的身份手动执行一次写入操作# 假设应用以 www-data 用户运行 docker exec -u www-data your-container-name sh -c echo test /app/storage/test.txt ls -l /app/storage/如果这一步失败报错Permission denied那问题就锁定在权限上。第五步检查宿主机资源最后才去怀疑宿主机。检查磁盘空间和内存# 宿主机磁盘 df -h # 宿主机内存 free -h # Docker 的磁盘使用情况 docker system df -v很多看似是 Docker 的问题根源其实是宿主机磁盘满了或者内存不足导致 Docker Daemon 无法正常工作。4.3 我的个人经验三条铁律在无数个项目交付后我给自己立下了三条不可动摇的铁律它们已经融入了我的日常开发和运维习惯“Volume 优先”铁律在任何需要持久化数据的场景无论是开发、测试还是生产默认选择 Volume。只有当你有非常明确、不可替代的理由比如必须复用宿主机上一个已有的、结构固定的配置目录才考虑 Bind Mounts。这条铁律帮我规避了 80% 的协作和迁移问题。“环境变量驱动”铁律永远不要在Dockerfile或应用代码中硬编码存储路径。必须通过环境变量如STORAGE_PATH来注入。这让你可以在docker-compose.yml中为不同环境dev/staging/prod配置不同的挂载方式而无需修改一行应用代码。docker-compose.yml中的volumes配置就是这条铁律的最佳实践载体。“日志即证据”铁律任何与存储相关的问题第一反应不是猜而是看日志。docker logs container是你的第一道防线。我习惯在app.py的关键 IO 操作前后都加logger.info()记录“即将写入 X”、“已成功写入 Y”。当问题发生时这些日志能精准地告诉你是应用没走到写入逻辑还是写入逻辑失败了还是写入成功了但挂载点不对。日志是你在容器迷宫中唯一的地图。5. 总结选择哪一把钥匙取决于你要打开哪一扇门写到这里关于 Docker 持久化存储的讨论其实已经超越了技术本身变成了一种工程决策的艺术。Bind Mounts、Volumes 和 tmpfs它们不是简单的“功能开关”而是代表了三种截然不同的数据治理哲学。当你追求极致的控制力和开发便利性并且愿意为这份便利承担额外的运维和安全责任时Bind Mounts 是你的“瑞士军刀”。它锋利、直接但也要求你时刻保持警惕就像驾驶一辆没有 ABS 的赛车。当你追求生产环境的稳定性、可移植性和可管理性并且希望数据的生命周期能够独立于任何单个容器、甚至单个宿主机时Volumes 是你的“黄金标准”。它可能不如 Bind Mounts 那么“所见即所得”但它为你构建了一个坚实、可靠、可扩展的数据底座。当你追求绝对的安全性和极致的性能并且你的数据天生就是“一次性”的它的价值只存在于容器运行的那几十秒或几分钟内时tmpfs 是你的“特工匕首”。它无声、迅捷、不留痕迹是处理敏感信息和高频缓存的不二之选。我见过太多团队在项目初期为了图快全用 Bind Mounts结果到了上线前一个月才发现路径在不同环境Mac/Windows/Linux下不兼容配置管理一团糟我也见过团队在生产数据库上错误地使用了 tmpfs导致服务重启后所有连接池配置丢失引发雪崩。这些都不是 Docker 的错而是我们作为工程师在做出选择时没有充分理解每一把钥匙背后的重量和责任。所以下次当你准备敲下docker run命令面对那个--mount参数时请暂停一秒。问问自己这个数据它的主人是谁它的生命有多长它需要被谁看见它是否足够敏感答案自然会告诉你该拿起哪一把钥匙。这就是我在这篇笔记里最想传递给你的东西。