企业官网建设流程全解析

从拿到 Dify 社区版源码到第一个 AI 应用真正能对话，我大概折腾过不少时间。第一次手动配环境、处理依赖、调模型接口，结果发现大量时间其实花在了部署环节，而不是在产品逻辑上。后来换成 Docker 方式重新走了一遍，整套流程压缩到 30 分钟以内，干净利落。所以这篇我直接分享自己实测下来的部署路径：用 Docker 一键拉起 Dify，再按 5 个步骤把 AI 应用从零跑到能上线。整个过程不涉及复杂编程，把关键参数和坑点都写清楚，适合刚接触 Dify 的开发者、正在做 AI 应用落地的产品经理，以及想在公司内部快速搭一套 AI 应用平台的技术同学参考。

1. 为什么用 Dify 搭 AI 应用，而不是直接调大模型 API

1.1 Dify 到底解决什么问题

Dify 是一个开源的大模型应用开发平台，官方定位是“LLMOps”，也就是把大模型应用的开发、调试、运营全流程打包起来。你不需要从零去写前端聊天框、后端 API、用户管理、日志追踪这一整套基建，Dify 把这些通用能力都内置好了，你只需要专注于业务逻辑和提示词设计。

拿对一个开发者的价值来说，Dify 相当于把“造轮子”和“用轮子”分开了。以前你想做一个基于大模型的客服机器人，要自己实现对话管理、上下文缓存、知识库检索、API 封装，还得考虑多用户并发导致的安全问题。用 Dify 之后，这些工作变成了配置项：知识库上传文档就能自动切分和向量化，对话历史自动维护，发布后自动生成可调用的 API 接口。

从我做过的实际项目看，Dify 目前最适合这几类场景。第一类是内部效率工具，比如给运营团队做的文案生成助手、给客服做的知识库问答机器人。第二类是面向外部用户的产品原型，用 Dify 快速验证业务逻辑，等有真实流量后再考虑是否自研。第三类是 RAG 类应用，Dify 的知识库功能对文档处理和检索做了大量封装，比你自己从零搭向量数据库再写检索链路要省力得多。

1.2 为什么部署首选 Docker Compose

Dify 官方提供了多种部署方式，包括 Docker Compose、Kubernetes、源码运行，其中 Docker Compose 是社区版最推荐、也最省心的方式。我之所以推荐 Docker Compose，核心原因是它把整个系统的依赖关系一次性解决掉了。

看一眼 Dify 的架构就知道，它不是一个单体应用，而是由 API 服务、Worker 异步任务、Web 前端、PostgreSQL 数据库、Redis 缓存、Weaviate 向量数据库等多个组件组成。如果手动部署，你需要分别安装和配置每一个组件，还要处理版本兼容问题。用 Docker Compose 之后，所有组件都被打包成容器，一条命令就能全部拉起，删除时也不会在宿主机上留下垃圾文件。

另一个重要因素是可移植性。不管你是用自己的 Mac 本调试，还是部署到 Linux 服务器，只要安装了 Docker，同一套 docker-compose.yml 文件就能跑起来。这对团队的协作和环境的统一很有帮助，我在本地调好之后，直接把配置传到服务器上，几乎不需要做额外调整。

2. 部署前的准备工作，少走弯路的关键

2.1 硬件和系统要求先确认清楚

在开始装之前，先确定你的机器满足 Dify 的基础要求。Dify 对硬件的要求比起自训练模型来说低得多，因为它本身只是调用大模型 API，不需要本地跑权重，占用资源的主要是数据库、向量检索和 Web 服务本身。

实测下来，Dify 社区版部署完成后的空闲内存占用大约在 2GB 到 3GB 之间，包含所有 Docker 容器。所以机器内存建议不低于 4GB，8GB 会更舒服。CPU 双核就能跑，四核会更稳。磁盘方面，Dify 镜像整体体积大约在 3GB 左右，加上日志和数据增长，建议预留 20GB 以上。

操作系统上，Linux 服务器是生产环境的首选，Ubuntu 20.04 或 22.04 我都测过，没什么兼容问题。如果你只是本地体验，Windows 10/11 和 macOS 也可以，但需要先装 Docker Desktop，用 WSL 2 后端跑 Linux 容器。我自己第一次是在 Windows 上跑的，踩了一些坑，后面会详细说。

2.2 Docker 和 Docker Compose 安装细节

Dify 的 Docker 部署依赖 Docker Engine 和 Docker Compose 插件，装的时候注意版本。Docker Engine 建议 20.10 以上，Compose 插件建议 2.x 版本，太老版本可能导致 docker-compose.yml 里的一些字段无法识别。

Ubuntu 上安装可以用官方脚本，但如果你有代理或镜像加速的需求，建议手动添加 Docker 官方源后安装。装完之后先验证一下宿主机能不能正常拉取镜像。

docker --version docker compose version

如果你是在 Windows 上玩，Docker Desktop 安装时有一步选择 WSL 2 还是 Hyper-V 后端，推荐选 WSL 2，性能更好而且和 Linux 的环境差异更小。安装完成之后记得在 Docker Desktop 的 Settings 里把资源调大，默认分配的 CPU 和内存往往不够 Dify 跑，我一般给到 4 核 8GB。

注意：Windows 下很多问题的根源是 Docker Desktop 资源配额不足，容器被强制杀掉或者启动超时。如果你发现 Dify 启动后过一会儿 Web 页面就打不开了，第一件事去把 Docker Desktop 的内存调大。

3. 30 分钟完成 Dify Docker 部署

3.1 获取 Dify 源码和 Docker Compose 配置

Dify 的 Docker 部署文件是随源码仓库一起发布的，所以第一步是拉取 Dify 的 GitHub 仓库。不需要拉完整的历史记录，加--depth=1只拉最新代码就可以。

git clone --depth=1 https://github.com/langgenius/dify.git cd dify/docker

进入dify/docker目录后，你会发现有几个关键文件。.env.example是环境变量模板，docker-compose.yaml是容器编排配置，ssrf_proxy目录是防 SSRF 攻击的代理组件，volumes相关目录用于持久化数据。如果 GitHub 拉取速度慢，可以用镜像站点替换，但要注意尽量选择可靠来源。

3.2 配置环境变量，这些参数要弄明白

Dify 的所有配置都集中在.env文件里，这个文件从.env.example复制而来。修改配置前先理解几个关键的变量，不要一上来就乱改。

cp .env.example .env

首先看SECRET_KEY，这是用于会话加密和应用密钥生成的，如果不设置，系统会随机生成，但每次重启都会变化，用户登录态会失效。所以你最好主动设一个固定值，长度至少 32 位。

然后是APP_PORT，这是映射到宿主机上的 Web 访问端口，默认是 80。如果 80 端口已经被占用，改成 8088 或者你喜欢的端口。改法是在.env里修改EXPOSE_NGINX_PORT，在旧版本里叫APP_PORT，注意看你下载的版本对应的变量名。

如果你要使用通义千问、智谱、Ollama 等国内外模型，还需要修改MARKETPLACE_ENABLED和模型供应商相关的环境变量。但我的建议是，部署阶段不要纠结模型配置，先让 Dify 跑起来，进管理后台再加模型供应商，可视化操作更清晰。

3.3 一键启动，等待容器就绪

执行启动命令之前，先拉一遍镜像，可以直观看到要下载多少东西。

docker compose pull

这个命令会拉取 Dify 相关的所有镜像。镜像下载时间取决于网络环境，如果是在国内服务器上，建议先配置好镜像加速器，否则拉镜像可能就花掉 20 分钟。配置加速器的方法通常是在/etc/docker/daemon.json里添加 registry-mirrors 字段，然后重启 Docker。

镜像拉完之后，直接启动。

docker compose up -d

-d参数表示后台运行。启动后查看容器状态：

docker compose ps

如果你看到所有的容器状态都是running，说明启动成功。如果有些容器是restarting或者exited，说明出问题了，可以用下面的命令看具体日志。

docker compose logs -f api

实操提示：首次启动时，API 服务和 Worker 都在初始化数据库并执行迁移，这段时间 Web 界面可能暂时打不开，大概需要等 30 秒到 1 分钟。不用急着反复重启，看api的日志出现Running on之类的字样就说明服务就绪了。

3.4 初始化账号，进入 Dify 控制台

启动完成后，浏览器访问http://localhost:80（如果你改了端口就是http://localhost:你的端口）。第一次打开会进入初始化页面，需要设置管理员邮箱和密码。这里要注意：邮箱不需要真实可收信，只要是合法格式就行，因为 Dify 社区版暂时不会发验证邮件。

设置完管理员账号后，系统会自动登录并进入 Dify 的首页。至此部署环节完成，用时大概 10 到 15 分钟。剩下的时间，就是上线你的第一个 AI 应用。

4. 五个步骤上线你的第一个 AI 应用

4.1 第一步：接入模型供应商

Dify 本身不提供大模型算力，它通过模型供应商来调用各种大模型 API，包括 OpenAI、Azure OpenAI、通义千问、DeepSeek、智谱、Ollama 本地模型等。你需要在 Dify 后台的“设置”页面，找到“模型供应商”，填入相应的 API Key。

以 DeepSeek 为例，先去官网注册账号并创建 API Key，然后回到 Dify 的模型供应商页面，选择 DeepSeek，填入 API Key。Dify 会自动校验 Key 的有效性，校验通过后在“模型”列表里就能看到可用的模型了。

这里有一个关键决策：选哪个模型作为默认模型。我的经验是把最强的模型设为 Agent 和推理场景的默认模型，同时在“系统模型”设置里把“通用模型”“Embedding 模型”分别选好。Embedding 模型是知识库功能必需的，如果你需要做 RAG 应用，建议提前配好，Dify 默认推荐 OpenAI 的text-embedding-3-small，但如果你的服务器无法访问 OpenAI，就选国内供应商的 Embedding 模型。

4.2 第二步：创建应用，配置提示词

模型接入之后就进入了真正有意思的部分。在 Dify 首页点击“创建应用”，你会有几个选择：聊天助手、文本生成、Agent、工作流。对于第一次体验，建议从“聊天助手”开始。

创建聊天助手应用后，进入“编排”页面。左边是提示词编排区域，右边是预览对话区域。你需要做三件事：写系统提示词、选模型、设置参数。

写提示词时不要用“你是 AI 助手”这类太笼统的说法。举个例子，你要做一个“小红书文案生成助手”，系统提示词可以这样写：

你是一位熟悉小红书平台风格的内容创作者。用户会给你一个产品描述或话题，你需要生成一篇包含标题、正文、话题标签的小红书文案。标题要求有吸引力，正文要求口语化、真诚，避免使用过度营销词汇。

模型参数里面，Temperature建议从 0.7 开始调。它控制的是输出的随机性，数值越高越有创造性，但更容易跑偏；数值越低越稳定，但可能显得呆板。不同的业务场景要选不同的策略，做客服问答可以调到 0.2 左右，做创意文案可以调到 0.8。

4.3 第三步：测试和调试，别跳过这一步

写好提示词后，右侧的预览区域可以直接输入内容进行测试。这一步千万不要省，我见过太多人配置完之后直接发布，结果用户一问就暴露问题。

调试时重点关注几个方面。第一是回复质量：如果不满意，优先调整提示词而不是模型参数，提示词的描述越具体，模型的表现越稳定。第二是响应速度：影响响应速度的主要是模型服务商的 API 延迟和网络链路，如果 Dify 部署在海外服务器但调用的是国内模型，延迟会明显增加，反之亦然。第三是成本控制：在“日志与标注”页面可以看到每次调用的 token 消耗，你可以据此估算运营成本。

Dify 的调试面板还有一个很方便的“思维链”功能，可以直接查看 Agent 或工作流每一步的执行过程，包括调用了哪些工具、检索了哪些知识库内容。这能帮你快速定位问题出在提示词、工具调用还是知识库检索环节。

4.4 第四步：发布应用到访问页面

调试满意之后，点击右上角的“发布”按钮。Dify 会为每个应用生成一个独立的 Web App 访问地址，链接形式是http://your-domain/chat/abcdef1234。你可以直接把这个链接发给用户，他们不用登录 Dify 后台就能使用这个应用。

Web App 的页面外观可以在“通用设置”里调整，包括应用的头像、名称、描述，以及是否允许用户重置对话等。如果你想嵌入到自己的网站，Dify 还提供了两种嵌入方式。一种是 iframe 嵌入，复制代码块直接粘贴到网页里就行；另一种是通过 JavaScript SDK 调用，适合定制程度更高的场景。

另外，Dify 的 Web App 有一个“公开访问”开关，默认发布后是公开的，也就是说任何拿到链接的人都能使用。如果你只是想让内部员工用，可以关闭公开访问，改为通过登录 Dify 账号后访问。具体选择取决于你的安全需求。

4.5 第五步：通过 API 集成到业务系统

Web App 适合快速使用，但如果你要集成到自己的业务系统，需要用 API 方式。Dify 为每个应用自动生成了服务 API 接口，你可以在应用的“API 访问”页面找到 API 密钥和接口地址。

API 的核心是/chat-messages接口，发送用户消息并返回模型回复，支持流式和非流式两种模式。下面是最小可用的 Python 调用示例：

import requests api_key = "app-xxxxxx" url = "http://your-domain/v1/chat-messages" headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" } payload = { "inputs": {}, "query": "帮我写一篇产品介绍文案", "response_mode": "blocking", "conversation_id": "", "user": "user-123" } response = requests.post(url, json=payload, headers=headers) print(response.json())

注意匹配conversation_id用于多轮对话，第一次请求时留空，Dify 会返回一个新的 conversation_id，后续对话带上这个 ID 才能保持上下文。在user字段传用户标识，方便后续做数据分析。

这里有一个容易踩的坑：不要在代码里硬编码 API Key。Dify 的 API Key 可以创建多个，并且可以随时吊销。生产环境建议通过环境变量或者配置中心管理密钥，定期轮换。

5. 常见问题与排查技巧实录

5.1 容器无法启动，挂在端口冲突

如果你本机已经有服务占用了 80 端口，Dify 的 nginx 容器会启动失败。表现是docker compose ps里nginx容器的状态为exited，查看日志会看到bind: address already in use的错误。

解决办法有两个。一个是你先停掉占用 80 端口的服务再重启 Dify。另一个更省事的是修改端口映射，直接在docker-compose.yaml里把80:80改成8088:80，或者改.env里的端口变量。改完之后执行docker compose up -d重新创建容器。

判断端口是否被占用的命令：

sudo lsof -i :80

5.2 镜像下载慢，启动等太久

这是国内服务器上最常见的问题。Dify 的镜像总量不小，一次性 pull 可能消耗很长时间。除了前面说的配置 Docker 镜像加速器，还有一个小技巧是分阶段拉取，先docker compose pull把镜像拉完再up -d，避免启动时现拉镜像导致的超时。

如果你用的是 macOS 的 Docker Desktop，可以在 Preferences 里的 Docker Engine 配置中直接编辑 registry-mirrors。Windows 的操作位置类似。配置格式参考：

{ "registry-mirrors": [ "https://docker.mirrors.ustc.edu.cn" ] }

5.3 升级后知识库报 internal server error

这个问题在实际使用中遇到得比较多，很多人在 Dify 升级版本之后，打开知识库或编辑文档时看到internal server error的报错。这个问题的核心原因是数据库迁移没有正常完成，或者某些表的字段和前端接口期望的不一致。

我先说判断方法：进入api容器的日志，检索关键字ERROR，大概率能看到 PostgreSQL 相关的报错信息。处理思路是备份数据库、清理旧的迁移记录、重新执行迁移。Dify 在升级时官方提供了一套升级脚本：

cd dify/docker docker compose down git pull origin main docker compose up -d

但我建议在执行升级前，先看一下 GitHub Release 页面的升级说明，社区版升级不能跨大版本直接跳，需要一步一步来。

5.4 常见问题速查表

6. 部署上线后的几个实用建议

Dify 部署完成、应用跑通只是第一步，真正要稳定运行还需要考虑一些开发环境里不会暴露的问题。首先是数据备份。Dify 的数据存储在 PostgreSQL 和向量数据库里，容器一旦误删，数据就丢了。我建议每天定时备份数据库，最简单的做法是写一个 cron 脚本，用docker compose exec执行数据库的 dump 命令。

第二个建议是日志监控。Dify 本身带有基础的日志面板，但生产环境下建议对接外部的日志收集系统。如果公司没有现成的监控体系，至少也要定期手动查看docker compose logs，确认没有异常报错。

第三个建议是版本升级策略。Dify 社区版更新非常频繁，几乎每周都有新功能或修复。但不要每次更新都追，我的经验是看 Release Notes，如果涉及安全漏洞修复或者你正好需要的功能，再考虑升级。升级前记得先备份数据和配置。我在实际操作中的体会是，Dify 的价值在于把你的精力从基建中解放出来，让你能专注于业务本身。所以当你发现自己在“维护 Dify”上花的时间比“使用 Dify”还多时，就该考虑调整自己的使用方式了。把部署尽可能简化，把时间留给真正需要思考的提示词设计、业务流程编排和用户体验优化，这才是用这类平台该有的姿态。

最后分享一个小技巧：如果你打算长期使用 Dify，可以在服务器上用域名加 HTTPS 反向代理的方式暴露 Web 服务，而不是直接暴露 IP 端口。这样既安全，也方便后续配置微信、飞书等渠道的 URL 回调。具体的反向代理配置可以用 Nginx 或 Caddy 完成，Caddy 对 HTTPS 证书的处理更自动化，对新手友好很多。