我最近帮人做了一次从零开始的Windows环境Dify离线部署整个过程跑下来最大的感受是网上讲离线部署的文章不少但大多数都停在docker save / docker load这一步真正涉及到插件怎么离线装、Dify版本差异怎么处理、Windows下哪些坑容易踩的部分几乎没有一篇写完整。所以这篇文章我不打算重复那些谁都会讲的入门步骤而是把我这次从镜像打包到无网环境落地再到插件部署的全过程包括中间踩过的坑、试错后确定的最终方案一条一条都记录下来。文章会围绕Dify 1.x版本以Windows Docker Desktop为运行环境如果你正打算在医院内网、生产隔离网或任何不能连外网的Windows机器上部署一套Dify这篇应该能帮你少走很多弯路。我先把这次部署的目标说清楚目标机器是一台Windows Server物理隔离没有任何外网连接需要部署完整的Dify平台包括Web界面、API后端、Worker、PostgreSQL、Redis、Weaviate或Qdrant、Sandbox还有插件系统要能用。在动手之前我把所有镜像、依赖、插件包全部准备好用移动硬盘带进去整个过程不需要目标机器通外网也不需要目标机器上执行任何拉取远端资源的操作。1. 离线部署的整体思路为什么必须在Windows上做这件事先聊一个大家可能忽略的问题Dify官方文档的部署章节里对Linux的覆盖非常完整systemd、docker compose、裸机跑都有明确说明但Windows相关的说明几乎只有一句Docker Desktop for Windows剩下全靠自己摸索。这导致很多团队在隔离网里选型时第一反应是那就上Linux但现实里确实存在Windows是唯一可选系统的情况——比如部分政企内网、医院科研网、工控网段服务器采购时就绑定了Windows Server授权或者运维团队只会维护Windows环境这时候在Windows上把Dify跑起来就是一个必须解决的命题。在Windows上做Dify离线部署核心思路和Linux是一样的先在一台能联网的机器上准备好全部镜像打包成tar文件通过移动介质拷贝进内网再在目标机器上执行load和compose up。但Windows有几个特性会直接影响流程设计第一是Docker的运行机制。Windows下Docker Desktop有两种后端Windows容器和WSL 2后端。Dify的镜像全是Linux镜像所以必须用WSL 2模式。这意味着你load进去的镜像实际上是被存进了WSL 2的虚拟磁盘文件里而不是Windows文件系统的某个普通目录。理解了这一点你才能明白为什么很多人发现Docker Desktop里明明能看到镜像但C盘空间却越来越小因为这本质上是虚拟磁盘在增长后面我会专门讲怎么处理这个空间问题。第二是路径映射。Docker Compose文件里的volumes路径是容器内路径但宿主机路径在Windows下会有盘符和反斜杠的问题。Dify官方docker-compose.yaml虽然做了一些跨平台适配但实际跑起来你会遇到各种路径相关的边界情况尤其是Weaviate和Qdrant这类会把数据写在磁盘上的组件权限和路径的坑都非常典型。第三是插件机制的离线特殊性。Dify从0.6版本之后把插件系统重构成了插件市场独立容器模型插件的安装不再只是往代码目录扔一个文件夹而是要经过平台侧注册、依赖拉取、容器启动三个环节。在离线环境下这三个环节每个都可能卡住。比如插件市场拿不到列表比如某个插件依赖一个特定的基础镜像比如插件包签名校验失败。这些细节在官方文档里全都默认你的机器能联网所以离线部署时必须有一整套自己的处理流程。再回到整体思路上我这次选择的方案是在线机器为Win11装有Docker Desktop离线目标机器为Windows Server 2019也装了Docker DesktopWSL 2后端。两边的Docker引擎版本差距不能太大否则compose文件的某些语法可能出现兼容问题我这次两边都是Docker 24以上版本实测没有遇到问题。传输介质是格式化为exFAT的移动硬盘因为单个tar文件普遍在5~15GB之间exFAT可以绕过FAT32单文件4GB的限制同时NTFS在部分Windows Server默认策略下可能有写入权限问题exFAT反而是最省心的选择。这套方案的整体流程图我可以口述给你联网机器拉镜像 → 批量打tag → docker save输出tar → 移动硬盘拷贝 → 目标机器docker load → 解压Dify源码包 → 修改.env和docker-compose.yaml → docker compose up -d → 登录平台 → 离线安装插件包 → 验证对话和知识库检索。接下来每一节我都会展开讲实际执行时该怎么做。2. 镜像打包细节不是光docker save就够的2.1 正确识别Dify全部镜像清单Dify的docker-compose.yaml文件里定义了一组服务但这里有个最容易犯错的地方官方Compose文件在你直接执行docker compose up时会默认把需要联网拉取的镜像全部拉下来你如果只盯着docker images里的镜像列表去save可能会漏掉一些隐式依赖。我这次的做法是先把docker-compose.yaml完整跑起来一次在线机器上确保所有服务都是running状态然后通过docker compose images命令把当前项目实际使用的镜像列出来。我这次用的Dify版本是1.17.1现阶段我记得的最新社区版跑起来的镜像包括dify-api、dify-web、dify-worker同一套镜像、sandbox、postgres、redis、weaviate、nginx、ssrf_proxy以及plugin_daemon。如果你用的是更早的0.x版本可能还有elasticsearch但Dify在1.x里已经把知识库的默认向量库迁移到了Weaviate所以镜像清单会干净不少。这里的关键建议是不要手抄镜像名一定要用docker compose images输出结果作为打包清单这个输出会把repository、tag、image id全部列出来直接对着它做后续操作就不会漏。另外建议把Nginx的镜像也一并打包Dify的入口默认是Nginx做反向代理如果你在离线环境里需要把Dify暴露到局域网其他机器访问Nginx镜像必须存在如果你只在本机用localhost访问Nginx也是默认启动的所以无论如何都要打包。注意docker compose images输出的镜像ID比docker images里的IMPORT ID要长得多前者是真正的镜像ID后者是加载后的内部引用两者都能用但你在做save或load的时候如果用短ID有概率冲突所以后续操作我统一用repository:tag来做简单、直观、不容易错。2.2 从docker pull到docker save的完整命令处理在线机器上准备好镜像后我建议写一个小脚本批量打tag和导出而不是一条一条手敲。这里分享我用的参数逻辑首先我用一个文本文件images.list每一行是一个镜像的repository:tag然后循环执行#!/bin/bash # 在联网机器的bash环境或Git Bash下执行 while read image; do name$(echo $image | cut -d/ -f2- | tr / _ | tr : _) docker save -o dify_images_${name}.tar $image done images.list这个脚本把每个镜像导出成单独一个tar文件。为什么不干脆全部合成一个大tar两个原因一是在目标机器上load单个文件时如果其中一个损坏最多是重导这一个文件不用全部重来二是exFAT移动硬盘对超大单文件支持没问题但Windows文件系统在写入十几个GB的单个文件时一旦中途断电或拔盘整个文件就废了分成多个文件更稳。导出后一定要做的事情是计算校验值。Windows下用certutilLinux下用sha256sum。我这次把所有tar的SHA256都写进了一个文本文件拷到内网后先校验一遍再load这个习惯值得保留因为移动硬盘拷贝大文件偶尔会出现静默错误等load到一半才发现数据损坏排查成本很高。经验补充在WSL 2模式下docker save出来的文件默认放在当前shell的工作目录但如果你把tar文件直接放在Windows的C盘目录下会走一个跨文件系统的转换速度会慢很多。我建议在WSL内部先把所有tar导出到~/dify_offline目录再通过cp到/mnt/d/exfat_disk这样的Windows挂载点而不是直接在/mnt/d路径下执行docker save否则你会看到IO速度掉到几十MB/s。2.3 镜像save前需要统一版本和控制大小再强调一下版本匹配的问题。Dify的镜像tag通常是带版本号的比如dify-api:1.17.1、dify-web:1.17.1、dify-sandbox:0.2.x这些版本必须在同一个Dify版本下配套使用。如果你在线机器上之前拉过旧版本镜像又在不同时间拉过新版本docker compose up时它会以compose文件里指定的tag为准不会自动用最新版。所以我这次的做法是在打包前先docker compose down把旧容器清掉再用docker compose pull强制按compose文件里lock的版本重新拉一遍最后再save。控制大小可以从两个方向入手一是用docker image prune清理历史残留镜像避免误打包无关联的镜像二是注意PostgreSQL和Redis这两个组件的镜像体积通常不大100MB左右但Sandbox和API镜像内部包含Python运行时和一堆依赖体积可能到1GB以上整体算下来Dify全量镜像大概在6~8GB这个大小在移动硬盘上完全没问题但你得提前给临时目录留够空间。另外在save之前最好执行一下docker builder prune因为Docker Desktop的构建缓存可能占几十GB不清理会导致磁盘空间不足。3. 无网Windows目标机的部署执行全流程3.1 目标机Docker环境准备先确认WSL 2和磁盘空间目标机是Windows Server 2019离线环境安装Docker Desktop之前你必须提前准备好两个离线安装包一个是Docker Desktop Installer.exe另一个是适用于x64的WSL 2内核更新包wsl_update_x64.msi。如果你只装了Docker Desktop但WSL 2内核没更新Docker Desktop会提示WSL 2 installation incomplete然后一直起不来。这两个安装包都要在联网机器上下好带进去。安装顺序有讲究先安装WSL 2内核再安装Docker Desktop。WSL内核的安装很简单双击msi一路下一步即可但在部分Windows Server上需要先启用适用于Linux的Windows子系统和虚拟机平台两个Windows功能。这俩功能在离线环境下可以从PowerShell用Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux -All和...VirtualMachinePlatform -All开启不需要额外下载文件前提是系统镜像里的功能包完整。Docker Desktop安装时有个参数值得注意如果你有管理员权限建议用msiexec /i DockerDesktopInstaller.exe /quiet方式静默安装然后默认用WSL 2后端。装完后第一次启动可能会提示需要重启系统这是正常的。再确认一下Docker Desktop要用Windows登录用户权限跑不建议用system账户跑否则后面挂载卷会有权限问题。磁盘空间方面因为Dify镜像导入后全部在WSL 2的ext4.vhdx虚拟磁盘里建议你提前确认WSL 2发行版的默认磁盘位置所在分区至少有20GB以上空闲空间。Docker Desktop默认会把WSL数据放在C盘Users目录下如果你把Docker Desktop安装在D盘但WSL数据还是在C盘所以别搞混了。可以在PowerShell里用wsl -l -v查看当前发行版再找到对应的ext4.vhdx路径确认剩余空间。如果C盘空间不足可以考虑把整个WSL发行版迁移到D盘命令是wsl --shutdown wsl --export docker-desktop-data D:\wsl\docker-desktop-data.tar wsl --unregister docker-desktop-data wsl --import docker-desktop-data D:\wsl\docker-desktop-data D:\wsl\docker-desktop-data.tar注意docker-desktop-data这个发行版如果你之前就启动过unregister会清掉已有镜像数据所以这个迁移操作要在还没导入任何镜像之前做否则先备份镜像再迁移。3.2 镜像导入docker load的正确操作方式把移动硬盘插到目标机后先做校验再load。如果你的tar文件是多个独立的可以用PowerShell循环处理Get-ChildItem E:\dify_offline\*.tar | ForEach-Object { docker load -i $_.FullName }这里我特别想提醒一个Windows下的体验差异docker load在WSL 2模式下输入输出走的是Windows路径到WSL的转换速度会比Linux原生慢一些但一般不至于出错。如果load到一半报错Error processing tar file先不要慌八成不是镜像损坏而是磁盘空间不足或tar文件被移动硬盘的文件系统截断了。先用certutil校验SHA256再确认C盘空间最后再检查一下tar文件的实际大小和在线机器上是否一致。load完之后用docker images确认所有镜像都在并核对仓库名和tag。有些镜像在save时tag里带版本号load后也是带版本号的但如果你导入的是没有tag的镜像IDDocker会显示为 这种后面compose up会因为找不到匹配tag的镜像而失败所以导入后一定要逐个确认。3.3 Dify源码与配置准备.env和docker-compose.yaml镜像导入只是第一步接下来要把Dify的源码包拷进目标机。我这次是用1.17.1版本的release源码包dify-1.17.1.zip解压后进到docker目录你会看到一个.env.example文件。官方文档让你执行cp .env.example .envWindows下可以用copy命令但要注意Windows的copy在某些区域设置下会往文件里追加BOM头docker compose解析.env时如果遇到BOM可能会在变量名里混入不可见字符导致配置不生效。所以我在Windows上更推荐用PowerShell的Copy-Item或者直接用VS Code打开.env.example后另存为.env这样能避免BOM问题。.env文件里的关键配置项有这些SECRET_KEY、POSTGRES_PASSWORD、DB_PASSWORD、VECTOR_STORE、WEAVIATE_ENDPOINT、STORAGE_TYPE等。离线部署时主要需要确认以下几点第一VECTOR_STORE要和你打包的镜像匹配。如果你打包了Weaviate镜像就保持weaviate如果你选用Qdrant就要确认也打包了qdrant镜像并设置对应的Qdrant相关变量。第二STORAGE_TYPE默认是local意味着上传的文件会存在本地的volumes目录这个离线环境没有影响默认就可以。第三SECRET_KEY是Dify加密会话数据用的密钥离线环境无所谓安全性下限但建议还是换一个长随机字符串避免使用example里的默认值因为默认值在公网GitHub上大家都能看到。docker-compose.yaml文件也有几处需要调整。Dify的compose文件里所有镜像都用image字段指定了具体tag这部分不需要改你只需要检查两个点一是ports映射默认nginx会把80端口映射到宿主机如果你目标机80端口已经被别的服务占用需要改成8080之类二是env_file字段确认它指向了你的.env文件。改完之后在docker目录下执行docker compose up -d正常情况下首次启动会创建容器并加载镜像。因为镜像已经全部在本地所以不会触发拉取。如果过程中仍然有pull access denied或manifest unknown的错误说明某个镜像的tag不对或镜像没load成功回到docker images去查。3.4 启动验证与常见启动失败信号启动后第一步是等所有容器状态变成healthy。用docker compose ps查看状态其中api、worker、web、sandbox、weaviate、postgres、redis、plugin_daemon这些容器至少应该是Up状态。我这次遇到的一个典型情况是nginx容器和api容器起来了但web容器反复重启日志显示TypeError: Cannot read properties of undefined (reading X-...)。这种往往不是镜像问题而是web容器启动时连不上后端API检查.env里CONSOLE_API_URL和APP_API_URL的配置如果配置的是localhost或局域网IP确保网络能通并且端口映射没有冲突。另一个常见信号是sandbox容器起不来日志里报Failed to connect to the daemon。sandbox在Dify里是一个隔离代码执行环境它需要一个网络参数或一个可以连到的地址通常情况下它通过dify-api访问。如果API容器没起来sandbox会一直重试。这时候可以按依赖顺序手动启动先起postgres和redis再起api再起worker和sandbox最后起web和nginx。用docker compose up -d --no-deps按顺序启动能排查出到底是谁依赖谁。4. 插件部署的离线处理最容易踩坑的部分4.1 Dify插件机制的基本结构和离线难点Dify从1.x版本开始把插件机制做成了平台侧管理容器运行的架构。一个插件通常包含几个东西插件包本身.difypkg格式、插件依赖的Python包或Node包、以及插件运行时可能需要的外部服务比如某些插件要用到vector store或者搜索引擎。在在线环境里你在Dify后台的插件市场里点一下安装它会自动下载.difypkg并启动一个插件容器在离线环境里这个链路必须手动拆解。离线部署插件我总结下来有四个难点一是拿不到插件市场的列表和安装包二是插件包安装时平台会校验来源离线包需要手动导入三是部分插件依赖独立的sidecar容器或额外的Python依赖离线时这些依赖不会自动下载四是插件运行时的网络权限默认是受限的如果你做一些调用外部API的插件还需要在插件配置里设置允许访问的域名白名单但离线环境通常没有外部域名可访问所以这一步基本跳过。4.2 插件包的获取与离线导入.difypkg的完整流程如果你是在联网机器上先通过Dify平台进入到插件页面找到你需要安装的插件点击下载按钮拿到.difypkg文件。但这里有个小窍门Dify的插件下载链接有时需要身份认证你直接在浏览器里复制链接不一定能下到建议在能登录Dify平台的前提下用浏览器的开发者工具把真正的下载URL前缀截取出来或者直接使用Dify API的方式下载。下载完成后把.difypkg文件拷贝进内网。在目标平台里导入插件包的路径是登录管理员账号进入插件页面点击右上角的安装插件或类似按钮选择通过本地文件导入然后选择.difypkg文件。导入后平台会解析插件包此时要注意两点第一如果插件包依赖一个特定的基础镜像Dify会尝试拉取镜像。离线环境必须提前把那个基础镜像也打进tar并docker load进去。我在实际部署里遇到过好几个插件它们的依赖镜像在docker-compose.yaml里根本没有比如一些数据处理插件会依赖python:3.10-slim或node:18-alpine这些镜像体积不大但漏掉的话插件安装会在正在启动运行时这一步失败。第二插件包导入时Dify会做依赖检查它会检查插件metadata文件里声明的依赖是否已经在平台内。如果缺失会明确提示missing dependency。例如我这次装了一个文档解析插件它依赖dify-plugin-daemon的某个版本这时你必须确保plugin_daemon容器已经升级到对应的版本。如果版本不匹配可以先在联网机器上把plugin_daemon镜像和Dify平台一起升级再重新打包导入。关于插件市场的离线玩法还有一种取巧方式在联网机器上进入Dify插件市场页面把所有你需要的.difypkg文件下载到一个文件夹里放进移动硬盘然后内网导入。不需要搞什么离线Marketplace镜像服务因为Dify支持的本地导入就是直接从.difypkg文件安装足够完成90%的需求。4.3 插件安装后的登录与验证插件装完以后你在Dify平台的插件页面能看到它的状态变为已安装或运行中。但此时还不算完Dify部分插件需要你在设置-模型供应商里激活比如你会安装一个LLM适配插件你必须先在插件里配置模型API地址和密钥才能在应用编排里使用。离线部署大模型时通常都会接本地推理服务比如Ollama或其他兼容OpenAI接口的服务你需要把本地推理服务的API地址填到插件配置里。这里注意如果你在Docker容器里跑Dify要让它访问宿主机上的Ollama服务不能填localhost而要填host.docker.internal或宿主机在Docker网络里的实际IP否则会连接不上。验证插件是否真正可用我的建议是不要直接在生产应用里试而是新建一个空的聊天助手应用在编排页面里选择刚装好的模型供应商发一个最简单的你好看看模型返回是否正常同时查看插件容器的日志。如果日志里出现401或404优先检查API地址、API Key、模型名这三个配置。5. 离线部署常见问题与排查技巧实录这一节我把这次部署里真正踩过的坑都列出来每条都是真实发生且需要花时间排查的。有些问题你网上搜不到现成答案因为场景太特定。5.1 docker pull动作仍然发生或镜像加载不全最常见的问题是docker compose up -d时仍然报pull access denied。即使你load过所有镜像compose在启动前会先比对本地是否存在镜像如果存在就不会拉取。但有一个例外情况如果你load进去的镜像repo:tag和compose文件里写的repo:tag完全一样但Docker引擎层还是发起了pull多半是因为registry字段不同比如compose里写的是langgenius/dify-api:1.17.1而你之前load的镜像仓库名是dify-api:1.17.1两者会被当成不同镜像。解决办法是在在线机器上打包前用docker tag把镜像设置成和compose文件里一致的完整仓库路径名不能省掉组织名。5.2 Windows路径符引发的卷挂载失败在Windows下docker compose里的volumes如果写成绝对路径比如D:/dify/docker/volumesDocker Desktop会做转换但如果你用的是反斜杠D:\dify\docker\volumes在某些YAML解析器里会被当作转义字符导致compose解析失败。我这次全程用的是相对路径compose会以docker-compose.yaml所在的目录为基准创建./volumes目录这样最稳。如果遇到目录创建失败或权限拒绝用管理员身份打开PowerShell再执行docker compose up -d。5.3 插件容器一直CrashLoopBackOff插件装上了但插件容器一直重启日志里最常见的是ImportError: libGL.so.1或ModuleNotFoundError。这是因为插件依赖的Python包没装全而在离线环境里插件runtime容器启动时不会自动pip install这些依赖因为根本没网。解决办法是不要指望插件容器自己装要在联网机器上把插件依赖下载好然后通过plugin_package的requirements或通过构建自定义插件镜像的方式把这些依赖烧进去。这个操作比较进阶简单的做法是优先选择那些依赖少的纯API调用型插件避免在离线环境装重量级文档解析、OCR识别类插件。5.4 移动硬盘拷贝导致的文件损坏我这次遇到过一次tar文件在拷贝后能被docker load一部分、但中途报unexpected EOF的情况。排查发现是移动硬盘在拷贝大文件时因为供电不足导致写入失败文件表面上还在但末尾部分全空。校验SHA256时发现对不上。解决方案是拷贝完成后立刻校验不要等进内网才发现另外尽量用带独立供电的硬盘盒或SSD移动硬盘不要用那种USB供电不稳的小型硬盘。5.5 WSL 2虚拟磁盘无限膨胀Dify跑起来后日志、向量数据库、上传文件全都在WSL 2虚拟磁盘里长时间运行后ext4.vhdx会越来越大。你就算在Dify后台删除旧数据这个vhdx文件也不会自动收缩。建议定期执行以下操作回收空间wsl --shutdown Optimize-VHD -Path C:\Users\用户名\AppData\Local\Docker\wsl\data\ext4.vhdx -Mode Full这个Optimize-VHD命令在Windows 10/11和Windows Server 2019的Hyper-V管理工具里自带如果系统没装Hyper-V模块也可以用diskpart的compact vdisk命令效果类似。不过执行前一定要确保所有容器已经停止并且最好先做一次数据备份因为压缩过程操作不当可能损坏虚拟磁盘。5.6 域名与端口访问问题离线环境通常没有DNS解析你要访问Dify平台如果使用http://localhost直接访问一般没问题但如果要用局域网IP让其他机器访问你需要检查两处一是docker-compose里nginx端口是否绑定为0.0.0.0默认就是二是Windows防火墙是否放行了对应端口。我在Windows Server上测试时遇到过容器都正常但局域网访问超时最后发现是Windows Defender防火墙-高级安全里没有放行80端口手动添加入站规则后就好了。如果要给平台配HTTPS证书离线环境下建议直接在Nginx容器里挂载自签名证书而不是让平台层做TLS终止因为改Dify的配置在离线环境下链路更复杂。6. 效果对比与实际部署体验最后说一点这次部署完成后我的实际使用感受。Dify在Windows离线环境下跑起来之后整机资源占用处于一个可接受的范围Dify自身的API、Web、Worker、Sandbox、Plugin Daemon这五个核心服务加起来大约占2~3GB内存PostgreSQL和Redis各占几百MBWeaviate数据库根据知识库文档量大小内存占用会有明显波动但总体在3~4GB可完成中小规模文档的知识库检索场景。我实际部署的这台Windows Server配置是8核16GB同时跑Dify和一个本地推理服务轻量模型没有明显卡顿。如果你平时习惯用Linux部署切到Windows后最直接的不适应是日志查看方式。Linux下tail -f docker logs很方便Windows PowerShell的docker logs命令同样可以用但它输出的是CRLF行尾用grep过滤时偶尔会出现匹配不到的情况我习惯先docker logs 容器名 log.txt再打开分析。另外Windows下没有systemdDocker Desktop必须保持开机运行否则Dify服务会全部停掉。如果你希望Dify在机器重启后自动恢复可以写一个计划任务或把Docker Desktop的启动方式设为登录时自动启动再把docker compose up -d放到开机脚本里但要注意顺序必须先等Docker Desktop完全启动再执行compose否则会报Cannot connect to the Docker daemon。我的做法是用一个简单的PowerShell循环检测引擎就绪再执行compose实测稳定。插件这块离线部署时不要追求装太多重量级插件因为每个插件的运行容器和依赖都是独立的装多了不仅镜像体积膨胀而且排查问题的复杂度会成倍增加。我这次核心只装了三个一个本地模型的适配插件、一个知识库文档解析插件、一个API工具调用插件足够覆盖日常的对话应用与知识库查询场景。根据我这次在整个部署过程中走过的弯路我再整理几条关键建议第一在线机器上准备一份完整的镜像清单和插件清单不要临时去想还需要什么因为离线环境后悔成本极高第二所有文件传输必须校验完整性第三插件的.difypkg文件尽量多下载几个版本不同插件对daemon版本的要求差异很大版本不匹配时你可能需要在离线环境做平台升级那又是另一轮镜像打包流程。这次整个过程从准备到落地花了大概两天其中真正部署只占半天大多数时间都花在排查插件的依赖和Windows环境下各种边缘情况上。如果你操作时碰到某一步推不动可以回头对照一下我上面写的几个模块大概率能定位到问题。