简介面向参加 Dify Hackathon 的开发者内容聚焦在 Windows 10/11 下从零搭建 Dify 本地开发环境适合具备一定编程基础、熟悉 Git、Docker 与 Python 的技术爱好者尤其能帮赛前准备不足的团队快速补齐环境短板。文档以清晰步骤贯穿前置环境准备、克隆代码仓库、配置 .env 环境变量、docker-compose 启动全部服务、数据库迁移与管理员账户初始化等完整环节覆盖 Dify 从拉取代码到可访问 Web 界面的全过程同时针对 Docker 启动失败、端口占用、服务无法访问等高频故障给出了检查 Hyper-V/WSL 2、调整端口映射、查看容器日志等具体排查思路。资源为 docx 格式整包仅 1 个文件、15KB轻量便携适合部署时对照查阅或快速定位问题。目前已有 122 人学习文末还补充了应用创建、模型集成、插件扩展及 Hackathon 参赛建议能帮助读者从环境搭建平滑过渡到 AI 应用开发对希望在赛事期间快速迭代原型的开发者文档中的验证、停止与更新命令也能显著减少摸索成本是一份紧凑实用的上手指南。 如果你正坐在一台 Windows 笔记本前准备参加一场 Dify 相关的 Hackathon那这篇东西大概率能帮你比队友少踩半天坑。Dify 是当下相当主流的智能体应用开发平台能帮你把大模型、工作流、知识库和各种工具编排成一个可以现场演示的产品原型省去从零写前后端和编排逻辑的时间。但问题在于官方文档的部署说明默认是给 Linux 服务器写的换到 Windows 本地就会冒出一堆“意料之外”的状况Docker Desktop 起不来、WSL2 没配对、80 端口被占用、镜像拉不下来……这篇文章就是我从 Windows 上实际装 Dify、跑 Hackathon 项目的过程里抽出来的完整安装部署笔记适合准备参赛的开发者、想快速在本地玩 Dify 的同学以及所有不想在环境配置上耗太久的人。1. 准备阶段跑 Dify 之前先把 Windows 这边的 Docker 环境喂饱1.1 先搞清楚 Dify 在本地到底是怎么跑起来的Dify 不是一个单机软件它本质上是一组容器服务的集合至少包括 nginx、api、worker、web、PostgreSQL、Redis、向量数据库、sandbox、plugin_daemon 等十几个组件。官方用 docker-compose 统一编排这些服务目的就是让我们在任意一台能跑 Docker 的机器上把整套环境拉起来而不是一个个手动装依赖。理解了这一点你就明白 Windows 上安装 Dify 的真正核心工作其实是先把 Docker 环境准备利索然后让 compose 把整个“全家桶”拉起来。大多数人卡住并不是 Dify 本身的问题而是 Docker Desktop 没跑顺或者 WSL2 的资源分配不到位导致容器启动到一半就被系统杀掉。所以别急着去 git clone先检查宿主机。1.2 Docker Desktop 与 WSL2 的安装和资源分配在 Windows 上跑 Linux 容器主流方案就是 Docker Desktop WSL2 后端。前提条件是 Windows 10 2004 及以上版本或者 Windows 11并且 BIOS 里开启了虚拟化。如果没开虚拟化Docker Desktop 安装后大概率会直接报错连引擎都起不来。安装顺序建议这样走先在 PowerShell 里执行wsl --install安装 WSL2然后执行wsl --update把内核升到最新这一步很关键旧内核会出现 Docker 引擎无法启动的问题。装完 WSL2 后再装 Docker Desktop安装过程中会提示你是否启用 WSL2-based engine这里务必勾选。安装完打开 Docker Desktop 的 Settings在 Resources 选项卡里把内存调到至少 8GB、CPU 给到 4 核以上。提示如果你准备在 Hackathon 现场同时开浏览器、编辑器、录屏软件和 Dify那 8GB 只是底线建议预留 16GB。内存不够时最典型的症状就是 PostgreSQL 或向量数据库容器反复重启日志里全是 OOM 相关报错。1.3 一个容易被忽略的检查项磁盘空间和虚拟磁盘位置Dify 全家桶镜像加起来接近 10GB加上运行时的日志和数据建议磁盘剩余空间至少留 20GB。WSL2 的虚拟磁盘文件默认放在 C 盘如果 C 盘空间紧张可以在安装 WSL2 之后通过导出分发版的方式把虚拟磁盘迁移到 D 盘或者在 Docker Desktop 的 Resources 里调整 Disk image location。我个人的习惯是比赛前一天先装一遍把镜像全部拉好启动流程完整跑通然后在比赛当天直接开机验证。不要试图在比赛现场边拉镜像边写代码网络的不可控因素会把你逼疯。2. 拉取项目与配置这一步决定了后面会不会翻车2.1 获取 Dify 社区版代码与版本选择Dify 的整个部署其实只需要拿到官方仓库里的 docker 目录就够了。打开你的终端依次执行git clone https://github.com/langgenius/dify.git cd dify/docker这里有个版本选择的讲究。如果你参加 Hackathon我强烈建议不要用最新的 dev 分支代码而是用官方最新稳定版。你可以先执行git tag查看发布版本列表或者直接在 GitHub 的 Releases 页面下载对应版本的 zip 包。稳定版一般经过更多回归测试插件和模型供应商的兼容性更稳。2.2 .env 文件里值得动的几个参数进入dify/docker目录后你会发现一个.env.example文件。执行cp .env.example .env生成自己的配置文件。Dify 里大部分配置项都有默认值不需要都改但有几个关键参数你要知道是干嘛的。首先是最容易踩坑的EXPOSE_NGINX_PORT默认是 80。如果你本机的 80 端口已经被别的服务占用了启动后访问会失败或者跳到一个完全不相干的页面。解决方法很简单把这一项改成 8080 或者其他空闲端口之后访问地址就变成http://localhost:8080。其次是数据库和 Redis 的密码如POSTGRES_PASSWORD、REDIS_PASSWORD默认值在本地玩没问题但如果要部署成团队共享环境建议改成自己的强密码。注意VECTOR_STORE这个参数决定 Dify 用哪种向量数据库新版默认一般是 qdrant老版本常见 weaviate。如果你对这块不熟别动它Dify 已经封装好了改错了反而会起不来。2.3 镜像拉取加速与 compose 命令的坑国内网络环境下直接拉取 Docker Hub 镜像会慢到让你怀疑人生甚至直接超时。比较常规的解法是在 Docker Desktop 的 Settings - Docker Engine 里配置镜像加速地址填好之后点击 Apply Restart然后在终端执行docker info看到 Registry Mirrors 列表里有你的加速地址就说明生效了。另一个小坑是 docker compose 命令的格式。新版 Docker Desktop 自带 Compose v2推荐直接使用带横杠的docker compose而不是docker-compose。如果你在别的教程里看到docker-compose up -d在较新环境里可能会提示找不到命令这时候直接改成docker compose就行。3. 启动服务与初始化从命令行到可视化界面3.1 一键启动与日志观察配置文件准备好之后在dify/docker目录下执行docker compose up -d第一次启动会拉取大量基础镜像耗时取决于你的网速和镜像加速配置通常 20 分钟到 40 分钟不等。拉完之后用docker compose ps查看所有服务的状态。你会发现 Dify 有十几个容器每个都对应一个组件。此时不要急着打开浏览器先观察一下容器状态是否变成 healthy。你可以在终端执行docker compose logs -f实时跟踪日志输出。如果某个服务一直处于 restarting 状态日志里通常能看到具体原因比如磁盘空间不足、端口冲突、密码不一致等。结论是等到所有关键服务都是 healthy 状态再进浏览器否则你看到的往往是一片白屏或者 502。3.2 初始化管理员和登录服务全部就绪后打开浏览器访问http://localhost如果你改了端口就用对应的端口。如果一切正常会进入一个初始化页面让你设置管理员邮箱、用户名和密码。这一步填写的信息就是之后登录 Dify 后台的凭证建议用真实邮箱方便后续找回密码或接收通知。完成设置后会自动跳转到登录页用刚创建的管理员账号登录你就正式进入 Dify 的控制台了。到了这一步只能说环境装好了离真正能用的 AI 应用还差最后一步——把模型接进来。3.3 配置模型供应商对话、Embedding、Rerank 一个都不能少很多人装完 Dify 之后兴致勃勃地创建应用结果发现模型没法选、知识库传了文档却检索不了原因都是没有配置模型供应商。进入右上角头像菜单里的“设置”找到“模型供应商”这里至少需要配好三种能力第一是系统推理模型也就是对话和生成答案时用的主模型。如果你是 API 党直接配置 OpenAI、Anthropic、Azure OpenAI 等官方供应商填入对应的 API Key 就行。如果不想依赖外部网络或者现场网络不稳定推荐本地跑一个 Ollama然后在 Dify 里选择 Ollama 供应商。第二是 Embedding 模型知识库的向量化全靠它。比较经典的选择是text-embedding-3-small本地方案可以用bge-m3这类模型。Embedding 模型不配好知识库上传文档后处理会一直失败。第三是 Rerank 模型这个属于知识库检索的增强项不配也能用但配了之后检索精度会提升一个档次。Hackathon 时间紧的话可以跳过后续项目化再做优化。接入 Ollama 时有个常见的坑Dify 是跑在容器里的所以 base_url 不能填http://localhost:11434而要填http://host.docker.internal:11434。这个地址在 Windows 的 Docker Desktop 环境里会解析到宿主机 IP。另外Ollama 服务本身要监听0.0.0.0否则容器从内部访问不到宿主机上的模型服务。4. Hackathon 现场的三小时出 Demo 路线4.1 先定目标做一个能演示、能讲故事的最小闭环环境装好只是热身Hackathon 的真正难点在于有限时间内做出一个能打动评委的 demo。以我参加过几次黑客松的经验最稳的路线不是在 Dify 里堆一堆花哨的节点而是先明确一个业务场景然后搭一条最短的“输入 - 处理 - 输出”链路。在 Dify 控制台创建应用时你会看到两个入口聊天助手和工作流。我的建议是直接选工作流编排方式。聊天助手更适合快速体验对话效果但工作流更能体现你处理问题的工程化思路评委也更容易理解你的业务逻辑。一个经典的最小闭环是这样开始节点接收用户输入知识检索节点从知识库召回相关片段LLM 节点把检索结果拼进 Prompt 生成回答最后通过结束节点返回。这条链路在 Dify 里用可视化画布搭出来全程不到十分钟。4.2 工作流与知识库的快速组合如果你们团队的产品需要用到私有资料比如产品手册、论文、历史报表那知识库必须提前做好准备。在 Dify 里操作很简单左侧菜单进入“知识库”创建知识库后上传 PDF、TXT 或 Markdown 文档Dify 会自动完成分段和向量化。这里有两个现场容易翻车的细节。第一文档上传后要等它处理完处理中的知识库在检索节点里要么选不到要么检索结果为空。比赛现场如果文档量大这个等待过程会非常焦虑所以我强烈建议提前一天把知识库建好比赛当天直接复用。第二在“高质量”索引模式下文档向量化需要调用 Embedding 模型如果你用的是本地 Ollama 模型处理速度会比 API 慢不少。所以嵌入模型选型时优先考虑速度和稳定性。工作流搭好之后右上角可以一键“发布”Dify 会生成一个可公开访问的 WebApp 链接。这个链接可以直接发给评委体验也方便队友用手机扫码测试。你可以把它理解成给应用套了一层极简聊天界面省去自己写前端的功夫。4.3 给演示环境留个保底方案Hackathon 现场网络状况和供电状况都不可控所以一定要有备份思路。我一般会准备两个层面的兜底一个是模型层面的降级预案本地 Ollama 崩了就切换到 API 模型反之亦然另一个是演示层面的录屏方案把完整的流程提前录好一旦现场网络抽风或者模型响应慢直接放录屏至少能把故事讲完。另外Dify 的对话调试功能很好用你可以直接在画布右侧的调试面板里输入测试问题看到每一步节点的输入和输出。这个功能在评审前特别有用能快速确认是模型回答不好还是 Prompt 写得有问题还是知识库没召回内容。5. 常见问题与排查速查表5.1 端口被占用或访问不了安装页最常见的是访问http://localhost时出现 404 或者跳到其他页面。第一种情况是 80 端口被别的服务占用回到.env文件把EXPOSE_NGINX_PORT改成 8080然后执行docker compose up -d重新创建 nginx 容器。第二种情况是服务还没完全启动执行docker compose ps看一下 nginx 的状态等待它变成 healthy 再刷新页面。5.2 Docker Desktop 启动缓慢或引擎一直没起来如果在启动 Dify 之前Docker Desktop 本身就一直转圈先检查 WSL2 内核。在 PowerShell 执行wsl --status里面会显示内核版本。内核太旧的话执行wsl --update。如果更新完还是不行最简单的办法是执行wsl --shutdown关掉所有 WSL 实例然后重启 Docker Desktop。这个方法在 Docker Desktop 的引擎长时间 stuck 在 starting 的时候非常有效十次里有七八次能解决。5.3 容器反复重启、日志刷错怎么办遇到某个服务一直 restarting不要反复docker compose restart那样只会掩盖问题。正确姿势是执行docker compose logs 服务名比如docker compose logs db看看 PostgreSQL 到底报了什么错。我遇到过的常见原因有磁盘空间不足导致数据库写不进去、.env文件里数据库密码改了但 compose 文件里没同步、宿主机内存不够导致容器被 OOM killer 杀掉。这些信息都会在日志里体现出来。解决之后执行docker compose down再docker compose up -d让它干净地重新初始化。5.4 本地模型接入失败host.docker.internal 你真用对了吗Windows 上的 Docker Desktop 有个便利特性就是容器内可以通过host.docker.internal访问宿主机的服务。但如果你用 WSL2 模式偶尔会遇到这个地址解析失败的情况。这时候可以在 PowerShell 里执行ipconfig查看 WSL 网卡的 IPv4 地址然后把 base_url 填成这个 IP。另外Ollama 默认只监听 127.0.0.1这个也必须改成0.0.0.0否则即使在 Dify 里填对了地址容器里的请求也进不来。我在 Windows 上跑 Dify 踩得最多的就是模型接入这个环节尤其在本地模型和 Docker 容器之间来回调试时很容易忽略“容器里的 localhost 不是宿主机”这个基本事实。想清楚这一层问题大概率迎刃而解。本文还有配套的精品资源点击获取
简介面向参加 Dify Hackathon 的开发者内容聚焦在 Windows 10/11 下从零搭建 Dify 本地开发环境适合具备一定编程基础、熟悉 Git、Docker 与 Python 的技术爱好者尤其能帮赛前准备不足的团队快速补齐环境短板。文档以清晰步骤贯穿前置环境准备、克隆代码仓库、配置 .env 环境变量、docker-compose 启动全部服务、数据库迁移与管理员账户初始化等完整环节覆盖 Dify 从拉取代码到可访问 Web 界面的全过程同时针对 Docker 启动失败、端口占用、服务无法访问等高频故障给出了检查 Hyper-V/WSL 2、调整端口映射、查看容器日志等具体排查思路。资源为 docx 格式整包仅 1 个文件、15KB轻量便携适合部署时对照查阅或快速定位问题。目前已有 122 人学习文末还补充了应用创建、模型集成、插件扩展及 Hackathon 参赛建议能帮助读者从环境搭建平滑过渡到 AI 应用开发对希望在赛事期间快速迭代原型的开发者文档中的验证、停止与更新命令也能显著减少摸索成本是一份紧凑实用的上手指南。 如果你正坐在一台 Windows 笔记本前准备参加一场 Dify 相关的 Hackathon那这篇东西大概率能帮你比队友少踩半天坑。Dify 是当下相当主流的智能体应用开发平台能帮你把大模型、工作流、知识库和各种工具编排成一个可以现场演示的产品原型省去从零写前后端和编排逻辑的时间。但问题在于官方文档的部署说明默认是给 Linux 服务器写的换到 Windows 本地就会冒出一堆“意料之外”的状况Docker Desktop 起不来、WSL2 没配对、80 端口被占用、镜像拉不下来……这篇文章就是我从 Windows 上实际装 Dify、跑 Hackathon 项目的过程里抽出来的完整安装部署笔记适合准备参赛的开发者、想快速在本地玩 Dify 的同学以及所有不想在环境配置上耗太久的人。1. 准备阶段跑 Dify 之前先把 Windows 这边的 Docker 环境喂饱1.1 先搞清楚 Dify 在本地到底是怎么跑起来的Dify 不是一个单机软件它本质上是一组容器服务的集合至少包括 nginx、api、worker、web、PostgreSQL、Redis、向量数据库、sandbox、plugin_daemon 等十几个组件。官方用 docker-compose 统一编排这些服务目的就是让我们在任意一台能跑 Docker 的机器上把整套环境拉起来而不是一个个手动装依赖。理解了这一点你就明白 Windows 上安装 Dify 的真正核心工作其实是先把 Docker 环境准备利索然后让 compose 把整个“全家桶”拉起来。大多数人卡住并不是 Dify 本身的问题而是 Docker Desktop 没跑顺或者 WSL2 的资源分配不到位导致容器启动到一半就被系统杀掉。所以别急着去 git clone先检查宿主机。1.2 Docker Desktop 与 WSL2 的安装和资源分配在 Windows 上跑 Linux 容器主流方案就是 Docker Desktop WSL2 后端。前提条件是 Windows 10 2004 及以上版本或者 Windows 11并且 BIOS 里开启了虚拟化。如果没开虚拟化Docker Desktop 安装后大概率会直接报错连引擎都起不来。安装顺序建议这样走先在 PowerShell 里执行wsl --install安装 WSL2然后执行wsl --update把内核升到最新这一步很关键旧内核会出现 Docker 引擎无法启动的问题。装完 WSL2 后再装 Docker Desktop安装过程中会提示你是否启用 WSL2-based engine这里务必勾选。安装完打开 Docker Desktop 的 Settings在 Resources 选项卡里把内存调到至少 8GB、CPU 给到 4 核以上。提示如果你准备在 Hackathon 现场同时开浏览器、编辑器、录屏软件和 Dify那 8GB 只是底线建议预留 16GB。内存不够时最典型的症状就是 PostgreSQL 或向量数据库容器反复重启日志里全是 OOM 相关报错。1.3 一个容易被忽略的检查项磁盘空间和虚拟磁盘位置Dify 全家桶镜像加起来接近 10GB加上运行时的日志和数据建议磁盘剩余空间至少留 20GB。WSL2 的虚拟磁盘文件默认放在 C 盘如果 C 盘空间紧张可以在安装 WSL2 之后通过导出分发版的方式把虚拟磁盘迁移到 D 盘或者在 Docker Desktop 的 Resources 里调整 Disk image location。我个人的习惯是比赛前一天先装一遍把镜像全部拉好启动流程完整跑通然后在比赛当天直接开机验证。不要试图在比赛现场边拉镜像边写代码网络的不可控因素会把你逼疯。2. 拉取项目与配置这一步决定了后面会不会翻车2.1 获取 Dify 社区版代码与版本选择Dify 的整个部署其实只需要拿到官方仓库里的 docker 目录就够了。打开你的终端依次执行git clone https://github.com/langgenius/dify.git cd dify/docker这里有个版本选择的讲究。如果你参加 Hackathon我强烈建议不要用最新的 dev 分支代码而是用官方最新稳定版。你可以先执行git tag查看发布版本列表或者直接在 GitHub 的 Releases 页面下载对应版本的 zip 包。稳定版一般经过更多回归测试插件和模型供应商的兼容性更稳。2.2 .env 文件里值得动的几个参数进入dify/docker目录后你会发现一个.env.example文件。执行cp .env.example .env生成自己的配置文件。Dify 里大部分配置项都有默认值不需要都改但有几个关键参数你要知道是干嘛的。首先是最容易踩坑的EXPOSE_NGINX_PORT默认是 80。如果你本机的 80 端口已经被别的服务占用了启动后访问会失败或者跳到一个完全不相干的页面。解决方法很简单把这一项改成 8080 或者其他空闲端口之后访问地址就变成http://localhost:8080。其次是数据库和 Redis 的密码如POSTGRES_PASSWORD、REDIS_PASSWORD默认值在本地玩没问题但如果要部署成团队共享环境建议改成自己的强密码。注意VECTOR_STORE这个参数决定 Dify 用哪种向量数据库新版默认一般是 qdrant老版本常见 weaviate。如果你对这块不熟别动它Dify 已经封装好了改错了反而会起不来。2.3 镜像拉取加速与 compose 命令的坑国内网络环境下直接拉取 Docker Hub 镜像会慢到让你怀疑人生甚至直接超时。比较常规的解法是在 Docker Desktop 的 Settings - Docker Engine 里配置镜像加速地址填好之后点击 Apply Restart然后在终端执行docker info看到 Registry Mirrors 列表里有你的加速地址就说明生效了。另一个小坑是 docker compose 命令的格式。新版 Docker Desktop 自带 Compose v2推荐直接使用带横杠的docker compose而不是docker-compose。如果你在别的教程里看到docker-compose up -d在较新环境里可能会提示找不到命令这时候直接改成docker compose就行。3. 启动服务与初始化从命令行到可视化界面3.1 一键启动与日志观察配置文件准备好之后在dify/docker目录下执行docker compose up -d第一次启动会拉取大量基础镜像耗时取决于你的网速和镜像加速配置通常 20 分钟到 40 分钟不等。拉完之后用docker compose ps查看所有服务的状态。你会发现 Dify 有十几个容器每个都对应一个组件。此时不要急着打开浏览器先观察一下容器状态是否变成 healthy。你可以在终端执行docker compose logs -f实时跟踪日志输出。如果某个服务一直处于 restarting 状态日志里通常能看到具体原因比如磁盘空间不足、端口冲突、密码不一致等。结论是等到所有关键服务都是 healthy 状态再进浏览器否则你看到的往往是一片白屏或者 502。3.2 初始化管理员和登录服务全部就绪后打开浏览器访问http://localhost如果你改了端口就用对应的端口。如果一切正常会进入一个初始化页面让你设置管理员邮箱、用户名和密码。这一步填写的信息就是之后登录 Dify 后台的凭证建议用真实邮箱方便后续找回密码或接收通知。完成设置后会自动跳转到登录页用刚创建的管理员账号登录你就正式进入 Dify 的控制台了。到了这一步只能说环境装好了离真正能用的 AI 应用还差最后一步——把模型接进来。3.3 配置模型供应商对话、Embedding、Rerank 一个都不能少很多人装完 Dify 之后兴致勃勃地创建应用结果发现模型没法选、知识库传了文档却检索不了原因都是没有配置模型供应商。进入右上角头像菜单里的“设置”找到“模型供应商”这里至少需要配好三种能力第一是系统推理模型也就是对话和生成答案时用的主模型。如果你是 API 党直接配置 OpenAI、Anthropic、Azure OpenAI 等官方供应商填入对应的 API Key 就行。如果不想依赖外部网络或者现场网络不稳定推荐本地跑一个 Ollama然后在 Dify 里选择 Ollama 供应商。第二是 Embedding 模型知识库的向量化全靠它。比较经典的选择是text-embedding-3-small本地方案可以用bge-m3这类模型。Embedding 模型不配好知识库上传文档后处理会一直失败。第三是 Rerank 模型这个属于知识库检索的增强项不配也能用但配了之后检索精度会提升一个档次。Hackathon 时间紧的话可以跳过后续项目化再做优化。接入 Ollama 时有个常见的坑Dify 是跑在容器里的所以 base_url 不能填http://localhost:11434而要填http://host.docker.internal:11434。这个地址在 Windows 的 Docker Desktop 环境里会解析到宿主机 IP。另外Ollama 服务本身要监听0.0.0.0否则容器从内部访问不到宿主机上的模型服务。4. Hackathon 现场的三小时出 Demo 路线4.1 先定目标做一个能演示、能讲故事的最小闭环环境装好只是热身Hackathon 的真正难点在于有限时间内做出一个能打动评委的 demo。以我参加过几次黑客松的经验最稳的路线不是在 Dify 里堆一堆花哨的节点而是先明确一个业务场景然后搭一条最短的“输入 - 处理 - 输出”链路。在 Dify 控制台创建应用时你会看到两个入口聊天助手和工作流。我的建议是直接选工作流编排方式。聊天助手更适合快速体验对话效果但工作流更能体现你处理问题的工程化思路评委也更容易理解你的业务逻辑。一个经典的最小闭环是这样开始节点接收用户输入知识检索节点从知识库召回相关片段LLM 节点把检索结果拼进 Prompt 生成回答最后通过结束节点返回。这条链路在 Dify 里用可视化画布搭出来全程不到十分钟。4.2 工作流与知识库的快速组合如果你们团队的产品需要用到私有资料比如产品手册、论文、历史报表那知识库必须提前做好准备。在 Dify 里操作很简单左侧菜单进入“知识库”创建知识库后上传 PDF、TXT 或 Markdown 文档Dify 会自动完成分段和向量化。这里有两个现场容易翻车的细节。第一文档上传后要等它处理完处理中的知识库在检索节点里要么选不到要么检索结果为空。比赛现场如果文档量大这个等待过程会非常焦虑所以我强烈建议提前一天把知识库建好比赛当天直接复用。第二在“高质量”索引模式下文档向量化需要调用 Embedding 模型如果你用的是本地 Ollama 模型处理速度会比 API 慢不少。所以嵌入模型选型时优先考虑速度和稳定性。工作流搭好之后右上角可以一键“发布”Dify 会生成一个可公开访问的 WebApp 链接。这个链接可以直接发给评委体验也方便队友用手机扫码测试。你可以把它理解成给应用套了一层极简聊天界面省去自己写前端的功夫。4.3 给演示环境留个保底方案Hackathon 现场网络状况和供电状况都不可控所以一定要有备份思路。我一般会准备两个层面的兜底一个是模型层面的降级预案本地 Ollama 崩了就切换到 API 模型反之亦然另一个是演示层面的录屏方案把完整的流程提前录好一旦现场网络抽风或者模型响应慢直接放录屏至少能把故事讲完。另外Dify 的对话调试功能很好用你可以直接在画布右侧的调试面板里输入测试问题看到每一步节点的输入和输出。这个功能在评审前特别有用能快速确认是模型回答不好还是 Prompt 写得有问题还是知识库没召回内容。5. 常见问题与排查速查表5.1 端口被占用或访问不了安装页最常见的是访问http://localhost时出现 404 或者跳到其他页面。第一种情况是 80 端口被别的服务占用回到.env文件把EXPOSE_NGINX_PORT改成 8080然后执行docker compose up -d重新创建 nginx 容器。第二种情况是服务还没完全启动执行docker compose ps看一下 nginx 的状态等待它变成 healthy 再刷新页面。5.2 Docker Desktop 启动缓慢或引擎一直没起来如果在启动 Dify 之前Docker Desktop 本身就一直转圈先检查 WSL2 内核。在 PowerShell 执行wsl --status里面会显示内核版本。内核太旧的话执行wsl --update。如果更新完还是不行最简单的办法是执行wsl --shutdown关掉所有 WSL 实例然后重启 Docker Desktop。这个方法在 Docker Desktop 的引擎长时间 stuck 在 starting 的时候非常有效十次里有七八次能解决。5.3 容器反复重启、日志刷错怎么办遇到某个服务一直 restarting不要反复docker compose restart那样只会掩盖问题。正确姿势是执行docker compose logs 服务名比如docker compose logs db看看 PostgreSQL 到底报了什么错。我遇到过的常见原因有磁盘空间不足导致数据库写不进去、.env文件里数据库密码改了但 compose 文件里没同步、宿主机内存不够导致容器被 OOM killer 杀掉。这些信息都会在日志里体现出来。解决之后执行docker compose down再docker compose up -d让它干净地重新初始化。5.4 本地模型接入失败host.docker.internal 你真用对了吗Windows 上的 Docker Desktop 有个便利特性就是容器内可以通过host.docker.internal访问宿主机的服务。但如果你用 WSL2 模式偶尔会遇到这个地址解析失败的情况。这时候可以在 PowerShell 里执行ipconfig查看 WSL 网卡的 IPv4 地址然后把 base_url 填成这个 IP。另外Ollama 默认只监听 127.0.0.1这个也必须改成0.0.0.0否则即使在 Dify 里填对了地址容器里的请求也进不来。我在 Windows 上跑 Dify 踩得最多的就是模型接入这个环节尤其在本地模型和 Docker 容器之间来回调试时很容易忽略“容器里的 localhost 不是宿主机”这个基本事实。想清楚这一层问题大概率迎刃而解。本文还有配套的精品资源点击获取
