DeepSeek多平台部署：Ollama、Open WebUI与手机端接入

简介《DeepSeek多平台部署指南涵盖本地、手机端及Open WebUI部署详解》面向希望将DeepSeek模型落地到实际环境的开发人员与技术爱好者覆盖本地电脑、iOS/Android手机以及Open WebUI三类部署路径。内容围绕Ollama环境安装、模型拉取与终端交互展开并给出iPhone快捷指令配置API Key、Android借助Termux编译运行Ollama以及用Docker与Open WebUI搭建可视化界面的具体流程。资源包仅含1个docx文档大小约15KB篇幅紧凑便于按章节检索和随查随用。已有1521人学习说明其对入门与跨平台实践具有参考价值。读者可从中获得分平台操作指令、依赖安装顺序、模型下载与启动验证方法以及遇到权限、网络或服务未启动时的排查思路。对初学者而言文档按平台拆分步骤并提示关键验证环节可减少环境配置中的反复试错对开发者则便于快速选择本地或容器化方案并集成到项目适合作为自然语言处理与深度学习模型部署的轻量实践手册。1. 三个设备跑同一个模型先想清楚你要的是本地推理还是随时能用把 DeepSeek 多平台部署这件事拆开看难的从来不是模型本身而是路径选择。本地部署走 Ollama一条命令就能拉起 7B 量化权重代价是吃内存和显存手机端想随时用要么拿 Termux 硬编一个推理进程要么用快捷指令接一个 OpenAI 兼容端点想在局域网里让几个人一起用Open WebUI 加 Docker 是最省事的组合。这三条路服务的目标完全不同混着用必然翻车。这份材料适合已经把深度学习环境折腾过一轮、现在想把自然语言处理能力落到自己机器上的开发者。接下来的顺序是先把本地 Ollama 跑通并学会调参再解决手机端的两种接法然后用 Docker 把 Open WebUI 架起来做多人入口最后把踩过的坑和一套压测脚本交给你。模型部署的功夫八成在参数和网络上不在模型本身。2. Ollama 本地部署从 ollama pull 到 Modelfile 调参的四步2.1 装完先做三项自检别急着拉模型Ollama 的安装本身没什么技术含量macOS 走 dmg 或包管理器Windows 走安装包Linux 走官方脚本。真正容易出问题的是装完之后的三件事服务有没有起来、监听在哪个地址、模型目录落在哪个盘。很多人第一次装完直接ollama run结果发现拉下来的几十 GB 权重塞进了系统盘机器当场变卡这就是没提前看模型目录的下场。# Linux 用官方脚本安装macOS 也可以用 brewWindows 直接下安装包 curl -fsSL https://ollama.com/install.sh | sh # 自检三连版本、服务状态、已下载模型列表 ollama --version systemctl status ollama # macOS/Windows 没有 systemd跳过这行 ollama list # 确认监听地址与模型存储目录 ss -lntp | grep 11434 echo $OLLAMA_MODELS第一行是安装入口脚本会自动判断发行版并注册 systemd 服务。systemctl status ollama看的是守护进程是否 activeLinux 上如果显示 inactive先journalctl -u ollama -n 50看日志通常是端口被占或者显存初始化失败。ollama list在没有任何模型时输出表头这是正常现象不是报错。最后两行分别确认 11434 端口有没有被监听、模型权重会落到哪个目录OLLAMA_MODELS为空时默认在用户主目录下的.ollama/models权重动辄几十 GB建议提前用环境变量指到大容量磁盘。环境变量在 Linux 上要通过 systemd 覆盖文件写入直接 export 对守护进程无效这是个高频误解sudo systemctl edit ollama.service # 在编辑器里写入下面这段然后保存退出[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_MODELS/data/ollama/models EnvironmentOLLAMA_KEEP_ALIVE30m EnvironmentOLLAMA_NUM_PARALLEL2OLLAMA_HOST从默认的127.0.0.1改成0.0.0.0是为了让局域网里的手机和容器能连进来只在本机用就别改改了等于把接口暴露给同网段所有人。OLLAMA_MODELS指向大盘。OLLAMA_KEEP_ALIVE30m让模型在最后一次请求后驻留 30 分钟避免每次对话都重新加载权重代价是这段时间内存一直被占着。OLLAMA_NUM_PARALLEL2控制并发请求数每个并发槽都会额外占用一份 KV cache显存紧张时调到 1。改完执行sudo systemctl daemon-reload sudo systemctl restart ollama才生效。2.2 拉哪个档位显存与量化档位对照ollama pull后面的标签决定了一切。DeepSeek-R1 在 Ollama 库里有多个蒸馏档位标签拼错一个字符就是 manifest unknown这个错误信息看起来很吓人实际只是名字不对。标签里的模型名带连字符冒号后面跟参数量形如deepseek-r1:7b不是deepseekr1:8b也不是deepseek_r1。# 常用档位按机器配置挑一个 ollama pull deepseek-r1:1.5b ollama pull deepseek-r1:7b ollama pull deepseek-r1:14b # 拉完直接进交互模式退出用 /bye ollama run deepseek-r1:7bpull只负责下载并校验不启动推理run会在需要时自动补拉。交互模式里/bye退出、/?看命令、/clear清上下文这几个够日常用了。档位量化后体积量级建议内存/显存典型用途1.5b1~2 GB4 GB 内存即可语法检查、简单分类、老旧笔记本7b4~5 GB8 GB 内存 / 6 GB 显存日常问答、写代码片段本机首选8b5 GB 左右8~12 GB换了个底座中文风格略有差异14b9 GB 左右16 GB 内存 / 12 GB 显存长文档摘要、稍微复杂的推理32b20 GB 左右32 GB 内存 / 24 GB 显存接近可用的代码助手水平70b40 GB 以上多卡或大内存工作站个人机器上基本跑不动体积那一列是量化后的粗略量级实际会因量化和底座不同有出入别拿它当精确值。选档位的原则很简单先按内存的一半去挑留出系统和 KV cache 的空间有独显的优先看显存显存装不下的层会回落到 CPU速度掉一个数量级。1.5b 在轻薄本上确实能跑但回答质量只够做格式转换类的活别指望它写业务代码。2.3 Modelfile把提示词和采样参数固化下来直接在命令行里聊天没法控制上下文长度和采样温度每次都靠默认值长文档一进去就被截断。Modelfile 是 Ollama 的定制层可以把系统提示词、上下文窗口、采样参数打成一个新的本地模型名之后所有调用都用这个名字参数稳定可复现。# 保存为 Modelfile FROM deepseek-r1:7b # 上下文窗口默认 4096长文档场景提到 8192 或 16384 PARAMETER num_ctx 8192 # 采样温度写代码建议 0.2~0.4创意写作再往上调 PARAMETER temperature 0.6 PARAMETER top_p 0.9 # 单次生成上限防止模型啰嗦 PARAMETER num_predict 1024 SYSTEM 你是一名严谨的技术助理回答以可执行的步骤和参数为主不确定的内容直接说明不确定。 # 基于 Modelfile 创建一个派生模型 ollama create ds-tech -f ./Modelfile # 用新名字跑参数即为上面固化的那套 ollama run ds-tech # 查看这个模型的完整参数与模板 ollama show ds-tech --modelfileFROM指向已下载的基座不写版本号会取 latest。num_ctx是最值得改的参数默认 4096 token 在粘贴一份长报错日志时明显不够但每翻一倍KV cache 的显存占用也跟着涨7B 模型从 4096 提到 8192 大约多吃 0.5~1 GB16 GB 机器上提到 16384 要留意余量。temperature调到 0 附近会让输出变得刻板但稳定适合生成配置和 SQLnum_predict是给单次回复封顶防止模型在开放问题上无限展开。ollama show --modelfile能打印出实际生效的完整配置怀疑参数没吃进去时用它核对比猜快得多。2.4 转成 HTTP 服务原生接口与 OpenAI 兼容接口终端交互只适合自己试一旦要接脚本、接网页、接手机就得走 HTTP。Ollama 同时暴露两套接口/api/chat是原生格式/v1/chat/completions是 OpenAI 兼容格式。前者字段少、返回干净后者胜在生态绝大多数客户端默认按 OpenAI 协议发请求选它省掉适配层的活。import json import urllib.request payload { model: ds-tech, messages: [ {role: system, content: 你是技术助理回答简洁。}, {role: user, content: 解释一下 num_ctx 调大的代价。}, ], stream: False, temperature: 0.3, } req urllib.request.Request( http://127.0.0.1:11434/v1/chat/completions, datajson.dumps(payload).encode(utf-8), headers{ Content-Type: application/json, # 本地无鉴权时可留空接网关时必须带上 Authorization: Bearer local, }, methodPOST, ) with urllib.request.urlopen(req, timeout120) as resp: data json.loads(resp.read().decode(utf-8)) print(data[choices][0][message][content]) print(usage:, data.get(usage))这段用标准库就能跑不依赖第三方包。model填的是上一步ollama create出来的名字不填派生名就填deepseek-r1:7b。stream设成 False 方便脚本处理做打字机效果时改成 True 再按行读 SSE。timeout给到 120 秒7B 模型在纯 CPU 机器上生成一千字确实可能超过一分钟超时设小了会误判成服务挂了。返回里的usage字段包含 prompt 与 completion 的 token 数后面做压测就靠它算速度。注意把OLLAMA_HOST改成0.0.0.0之后同网段任何人都能调用你的模型且没有任何鉴权。放在家里或实验室内网尚可一旦要跨网段访问前面必须加一层带 Key 校验的反向代理。3. 手机端两条路iPhone 快捷指令与 Termux 编译的取舍3.1 iPhone快捷指令本质是个 HTTP 客户端iPhone 上没有能直接跑 Ollama 的环境所谓手机端部署实际是两层意思要么把手机当成一个瘦客户端请求打到别处的推理服务要么用系统自带的快捷指令拼一个最小可用界面。前者是绝大多数人的真实选择后者只是把入口做进了系统里。理解这一点很重要否则会一直在找iPhone 版 Ollama然后怀疑自己搜错了。具体做法是自建一个快捷指令用「获取 URL 内容」动作发 POST。需要准备的是一个 OpenAI 兼容端点可以是局域网里那台跑 Ollama 的机器也可以是自己搭的网关统一形如http://地址:端口/v1/chat/completions。请求体按下面的结构填{ model: deepseek-r1:7b, messages: [ { role: user, content: 把这段报错翻译成人话CUDA out of memory } ], stream: false, temperature: 0.3 }在快捷指令里搭四步第一步「文本」动作放上面这段 JSON第二步「获取 URL 内容」方法选 POSTURL 填端点请求头加一条Authorization值为Bearer 你的Key请求体选「文件」并指向上一步的文本第三步「从输入获取词典值」键路径填choices.1.message.content这是取第一条回复内容的写法第四步「显示结果」或「朗读文本」。参数上有两个地方容易出问题。stream必须显式设成false快捷指令的「获取 URL 内容」不处理流式分块开着流式拿回来的是一堆拼接不完整的 JSON。model字段要和端点上的模型名严格一致写成简写或者带大小写差异都会返回 404错误信息还只告诉你 not found不告诉你是哪个字段的问题。把快捷指令加到主屏或者绑定到操作按钮才算真正随时能用。注意快捷指令里存的 Key 是明文任何能拿到你手机的人打开快捷指令就能看到。这个 Key 应该单独签发、只给对话权限、并且设一个额度上限别把主密钥塞进去。3.2 AndroidTermux 里把 Ollama 编出来Android 这条路是真的在本地跑推理。Termux 提供一个接近 Linux 的用户空间装好编译链之后可以按官方仓库的流程把 Ollama 编译成 arm64 可执行文件。整个过程对手机的内存和散热是个考验但走通之后断网也能用。# 1. 基础环境更新源、装编译依赖 pkg update pkg upgrade -y pkg install git golang cmake clang make pkg-config -y # 2. 拿源码--depth 1 只取最新一次提交省流量省时间 git clone --depth 1 https://github.com/ollama/ollama.git cd ollama # 3. 生成并编译两步都要在仓库根目录执行 go generate ./... go build . # 4. 后台起服务并验证 ./ollama serve sleep 3 curl -s http://127.0.0.1:11434/api/version # 5. 拉模型并进入对话 ./ollama pull deepseek-r1:1.5b ./ollama run deepseek-r1:1.5b第 1 步装的是编译期依赖golang提供 go 工具链cmake和clang负责底层的 C/C 部分缺任何一个都会在go generate阶段报错。第 2 步的--depth 1是浅克隆注意这里是两个短横写成单个横杠会被当成别的参数。第 3 步go generate ./...和go build .之间有个空格拼成go generate./...会直接报未知命令。第 4 步的把服务放后台sleep 3是给它初始化时间curl拿到版本号 JSON 才算启动成功返回空或者连接拒绝说明进程已经挂了去看前台输出。第 5 步在手机上建议从 1.5b 起步7B 在 8 GB 内存的手机上会频繁触发系统杀后台。编译失败有两条常见退路一是换预编译产物官方仓库的 release 页面通常会挂 arm64 的二进制直接下载解压省掉整条编译链二是把GOMAXPROCS调低、关掉并行编译手机内存不够时go build会被 OOM killer 干掉表现为进程无声无息消失。# 内存吃紧时的编译姿势限制并行度、降低优化开销 export GOMAXPROCS2 go build -p 1 -o ollama-bin .-p 1限制同时编译的包数量GOMAXPROCS2限制运行时并行线程数。代价是编译时间变长但不容易被杀。编译完成后再把GOMAXPROCS恢复默认运行期还是需要多核的。3.3 两条路的取舍算力、续航与可维护性把 iPhone 和 Android 放在一起对比结论其实很清楚。iPhone 那条路是纯客户端手机不发热、不耗电但完全依赖网络和对端服务Android 那条路是本地推理断网可用、数据不出设备代价是手机发烫、电量掉得快、模型只能选最小的档位。维度iPhone 快捷指令Android Termux推理位置远端服务手机本地可用模型档位取决于对端7B/14B 都行实测 1.5b 舒适7B 勉强断网可用否是手机发热几乎无明显长对话会降频数据是否出设备是否维护成本改 JSON 和端点即可编译链脆弱系统升级可能重来一个折中的用法是两条都留着日常问答用快捷指令走局域网里的机器涉及敏感内容或者出差没网的时候切到 Termux 本地跑。这样既不用在手机上硬扛 7B也不会因为没网就彻底断掉。Termux 里还有几个必须处理的系统级问题。Android 会主动回收后台进程./ollama serve 起来的服务在切到别的应用几分钟后就被杀掉需要执行termux-wake-lock申请唤醒锁用完termux-wake-unlock释放。另外 Termux 的默认 home 目录在应用私有空间脚本和模型都放在那里卸载应用即清空重要配置记得定期导出。# 防止后台被系统回收 termux-wake-lock # 确认服务进程还在 pgrep -f ollama serve || echo 服务已退出需要重启termux-wake-lock会一直在通知栏挂一个常驻通知这是它能活下来的原因不是 bug。pgrep那条是给自己写的健康检查写进快捷脚本里省得每次都去翻进程列表。4. Open WebUI 加 Docker容器怎么连上宿主机的 114344.1 先解决网络容器里的 localhost 不是宿主机的 localhost这一步是整个 Open WebUI 部署里翻车率最高的地方。容器有独立的网络命名空间容器内的127.0.0.1指向容器自己而 Ollama 跑在宿主机上两者根本不在一个回环里。于是你在网页端看到的是模型列表加载失败日志里是一行连接被拒绝看起来像 Open WebUI 装坏了实际上是网络地址填错了。Linux 上最省事的做法是让容器直接用宿主机网络栈docker run -d \ --networkhost \ -v open-webui:/app/backend/data \ -e OLLAMA_BASE_URLhttp://127.0.0.1:11434 \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main--networkhost表示容器不建独立网络直接共用宿主机的端口和回环所以127.0.0.1:11434能通。-v open-webui:/app/backend/data是数据卷对话记录、用户、上传的文档全在这个目录不挂卷的话容器一删全没了这是第二个高频事故。--restart always让它在宿主重启后自动拉起。-d后台运行。镜像标签用main拿到的是最新主线追新有风险稳定优先的话换成具体的版本标签。macOS 和 Windows 上的 Docker Desktop 不支持真正意义上的 host 网络得换成host.docker.internal这个特殊域名docker run -d \ -p 3000:8080 \ -v open-webui:/app/backend/data \ --add-hosthost.docker.internal:host-gateway \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main-p 3000:8080把容器内的 8080 映射到宿主机 3000浏览器访问http://localhost:3000。--add-host那一行是给 Linux 上的兼容性兜底某些版本不自动解析这个域名。OLLAMA_BASE_URL用容器视角的地址不是宿主机的。注意宿主机上的 Ollama 也必须监听在可被容器访问的地址上。如果OLLAMA_HOST还是默认的127.0.0.1即便用--networkhost某些发行版的防火墙规则仍会拦下跨命名空间的连接。排查顺序是先curl宿主机自己的 11434再进容器curl一次两段都通才轮到查 Open WebUI 的配置。4.2 首次进入管理员账号与模型下拉容器起来之后浏览器打开对应端口第一件事是注册账号而且第一个注册的账号自动成为管理员后面注册的都是普通用户。这个设计省了初始化配置但也意味着服务一旦暴露在公网第一个访问的人就能拿到管理员权限。所以顺序应该是先在本机注册完管理员、改好密码再考虑要不要对外开放。登录后进设置里的模型页正常情况下会直接拉到宿主机上已经pull过的模型列表下拉选择即可。如果列表是空的按这三步查容器内的OLLAMA_BASE_URL对不对、宿主机 Ollama 是否在跑、从容器内部能不能curl通。第三步行不通就是网络层问题跟 Open WebUI 无关。Open WebUI 本身也可以代为下载模型界面里填模型名后它会把请求转给 Ollama 的拉取接口。这条路径适合不想开终端的人但下载进度在网页上刷新不及时大模型建议还是老老实实在宿主机上ollama pull。4.3 多人与持久化把容器当成有状态服务对待一旦不止一个人用配置的重点立刻从能跑通转成别丢数据、别互相踩。Open WebUI 的数据卷是唯一的状态载体升级镜像的标准流程是先docker pull新镜像、停旧容器、删旧容器、用同样的-v参数重新docker run数据卷不动配置和历史都在。直接docker rm忘了挂卷那就是真的从头再来。# 升级流程拉新镜像重建容器数据卷保持不变 docker pull ghcr.io/open-webui/open-webui:main docker stop open-webui docker rm open-webui docker volume ls | grep open-webui # 确认卷还在 # 再执行一次 4.1 里的 docker run参数与之前完全一致docker volume ls那行是升级前的确认动作看到卷名再往下走。重建时所有-e参数要跟原来一致特别是OLLAMA_BASE_URL漏了就会回到模型列表加载失败的状态。多人场景下还要关心两件事并发和上下文。多个用户同时提问时Ollama 那边的OLLAMA_NUM_PARALLEL决定了能同时处理几个请求超出的会排队表现为网页端转圈很久才出字。上下文长度则受num_ctx限制用户在网页里上传长文档做问答文档切块后的内容很容易超过 4096回复会莫名其妙地忘掉前面说过的内容这时候要回到 Modelfile 把num_ctx提上去。5. 避坑与排查五个真机上翻过车的坑5.1 拉模型报 manifest unknown现象执行ollama pull deepseekr1:8b返回Error: pull model manifest: file does not exist或者 404。原因标签拼写不符合仓库里的实际命名。模型名是带连字符的deepseek-r1冒号后面才是参数量中间不能省掉连字符也不能把冒号写成下划线。解决先用ollama list看本地已有的名字或者按官方库里的写法逐个试。正确的形式是ollama run deepseek-r1:7b。这类错误信息从不告诉你正确名字是什么只能靠对照。5.2 容器里连不上宿主机的 Ollama现象Open WebUI 起来了登录正常但模型下拉为空容器日志里是 connection refused。原因容器内127.0.0.1指向容器自身不是宿主机或者宿主机 Ollama 只监听回环地址跨命名空间访问被拒。解决Linux 用--networkhost并以127.0.0.1作OLLAMA_BASE_URLmacOS/Windows 用host.docker.internal并把宿主机OLLAMA_HOST设为0.0.0.0。验证方式是进容器curl一次宿主机地址通了再谈应用层配置。5.3 Termux 编译中途进程消失现象go build .跑到一半命令直接结束没有报错也没有产物。原因手机内存不足被系统的 OOM killer 杀掉。编译 Ollama 的峰值内存远超日常应用8 GB 机型尤其容易中招。解决export GOMAXPROCS2配合go build -p 1降低并行度关掉后台其他应用必要时先termux-wake-lock。实在编不过就下官方 release 的 arm64 预编译包跳过整条编译链。5.4 快捷指令返回 401 或 404现象iPhone 上运行快捷指令提示未能完成操作点开详情是 401 Unauthorized 或 404 Not Found。原因401 是请求头里的Authorization没带上或者格式不对必须是Bearer加一个空格再加 Key404 多半是端点地址少了/v1前缀或者model字段的模型名跟服务端不一致。解决把请求体里的stream设为false用curl在电脑上先复现同样的请求能通再回去改快捷指令。手机端出错时看不到响应体这是排查最麻烦的地方所以先在电脑上验证一遍。5.5 长文档问答突然失忆现象前几轮对话正常贴进一份长文档之后模型开始答非所问或者完全忽略文档内容。原因num_ctx默认 4096 token超出部分被静默截断模型根本没见过后面的内容。解决回到 Modelfile 把num_ctx提到 8192 或 16384 再ollama create重建同时确认显存够用。判断是否被截断可以看接口返回的usage.prompt_tokens如果它贴着 4096 这个数基本可以确定截断了。6. 统一入口与压测用 30 行脚本量出你的 token/s多端部署走到最后会发现一个很现实的问题电脑上填127.0.0.1手机上填局域网 IP容器里填host.docker.internal同一套东西三份配置改一处忘两处。我的做法是在宿主机上放一层轻量反向代理所有端统一指向它密钥校验也放在这一层后端换模型、换端口都不影响客户端。在验证这层代理之前先得知道自己机器的真实吞吐。下面这段脚本用标准库打点测首 token 延迟和生成速度两个数决定了你的机器能不能撑住多人使用import json import time import urllib.request BASE http://127.0.0.1:11434/v1/chat/completions MODEL ds-tech def bench(prompt: str, rounds: int 3): for i in range(rounds): payload { model: MODEL, messages: [{role: user, content: prompt}], stream: False, temperature: 0.2, } req urllib.request.Request( BASE, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json}, methodPOST, ) t0 time.perf_counter() with urllib.request.urlopen(req, timeout600) as resp: data json.loads(resp.read().decode(utf-8)) cost time.perf_counter() - t0 usage data.get(usage, {}) out_tokens usage.get(completion_tokens, 0) speed out_tokens / cost if cost 0 else 0 print( fround{i1} cost{cost:.2f}s fprompt_tokens{usage.get(prompt_tokens, 0)} fout_tokens{out_tokens} fspeed{speed:.1f} tok/s ) if __name__ __main__: # 一段会触发较长输出的提示便于观察稳定速度 bench(用不超过 300 字说明 KV cache 与上下文长度的关系。, rounds3)跑三轮取后两轮的结果第一轮通常包含模型首次加载的时间数字会明显偏低。cost是端到端耗时包含排队、预填充和解码三部分speed用输出 token 数除以总耗时是个偏保守的指标因为分母里含了预填充时间。想单独看解码速度把三次的speed拉平对比即可波动超过 30% 说明有别的进程在抢资源。completion_tokens为 0 时说明服务端没返回 usage多半是走了某个不透传统计的中间层这时候只能靠字数估算。几个实测出来的经验阈值7B 模型在纯 CPU 上跑5~15 tok/s 是正常区间低于 5 说明内存带宽被别的程序吃掉了有独显且模型能全放进显存时30 tok/s 以上很常见同一台机器上把num_ctx从 4096 翻到 16384预填充时间会明显变长长文档场景的第一句响应可能要等十几秒这不叫卡死是预填充在算。多人共用的机器上OLLAMA_NUM_PARALLEL2看着能提升吞吐实际是两个人分同一份算力各自的 tok/s 掉一半体验未必更好。还有一个容易被忽略的验证点把三层串起来之后用手机、电脑、网页端各发一次同样的请求比对usage里的 token 数是否一致。不一致说明某条链路上有中间层在做截断或者改写这是最隐蔽的一类问题光看界面是看不出来的。血泪经验是我第一次把这套东西搭完图省事没给数据卷做备份一次误删容器直接把两周的对话和上传文档清空了事后连后悔药都没处买。从那以后我每次动docker run之前都会先docker volume ls确认卷名、再导一份数据卷出来放在另一个盘上才敢执行重建。希望帮到你。本文还有配套的精品资源点击获取