007. HTTPS 证书与 Dify 工作流

学习目标

这一节把 HTTP 访问升级到 HTTPS，并继续解释 Dify 和报销审批流的关系。

学完后，你应该能理解：

• 为什么录音 API 需要 HTTPS；
• HTTP 和 HTTPS 在项目部署里的区别；
• 有域名和只有 IP 时，证书申请有什么不同；
• 自签证书为什么会被浏览器提示不安全；
• Nginx 里 80 和 443 两个 server 分别负责什么；
• Dify 如何参与报销审批流程。

为什么要启用 HTTPS？

当前项目里会用到浏览器录音能力。

录音涉及用户隐私，浏览器对这类 API 有严格限制：

• 如果页面运行在 localhost，通常可以调用；
• 如果页面通过普通 IP 或域名访问，通常必须启用 HTTPS；
• 没有 HTTPS，浏览器可能不开放录音 API。

后续实时语音识别需要：

1. 前端调用浏览器录音 API；
2. 前端把音频片段传给后端；
3. 后端调用语音模型做流式识别；
4. 前端把识别结果实时展示出来。

所以 HTTPS 不是可选装饰，而是某些浏览器能力的前置条件。

企业环境为什么必须 HTTPS？

真实企业项目里，HTTPS 也是基本要求。

HTTP 请求是明文传输，更容易被拦截和篡改。HTTPS 通过证书和加密，让浏览器和服务器之间的通信更安全。

可以先把 HTTPS 理解成：

HTTP + 安全证书 + 加密传输。

只要看到 SSL、TLS、证书这类词，就可以把它们和 HTTPS 安全访问联系起来。

有域名时申请证书

如果有域名，证书申请选择会多很多。

常见方式：

• 宝塔面板里申请 SSL 证书；
• 使用 Let's Encrypt 免费证书；
• 云平台提供的免费证书；
• 购买商业证书。

有域名时，证书机构更容易验证“这个域名属于你”，所以签发证书比较自然。

只有 IP 时怎么办？

学习阶段可能还没有域名，只能通过 IP 访问服务器。

只有 IP 时，证书选择会少很多。很多证书机构不愿意给单独 IP 签发证书，或者价格比学习服务器本身还贵。

课程里采用自签证书。

自签证书的特点是：

• 免费；
• 可以让 HTTPS 跑起来；
• 浏览器会提示不安全；
• 适合自己学习、演示和临时测试；
• 不适合正式商业网站。

如果只是自己学习，或者面试演示时说明这是自签证书，通常不影响项目展示。

自签证书为什么会提示不安全？

浏览器信任的是一批权威证书机构签发的证书。

自签证书不是这些机构签发的，所以浏览器无法确认它是否可信，就会提示：连接不是私密连接，或者网站不安全。

这不代表 HTTPS 配置完全失败。它只是说明证书来源不被浏览器默认信任。

生成证书文件

自签证书通常会生成两个文件：

文件	作用
证书文件	给浏览器看的公开证书
私钥文件	服务器自己保存的密钥

Nginx 配置 HTTPS 时，需要同时指定这两个文件路径。

证书的主题信息里要写当前服务器 IP 或域名，否则浏览器访问时会出现不匹配问题。

Nginx 配置 80 和 443

HTTP 默认端口是 80。

HTTPS 默认端口是 443。

Nginx 里通常会有两个 server 配置：

server	作用
监听 80	处理普通 HTTP 请求，或重定向到 HTTPS
监听 443	启用 SSL，处理 HTTPS 请求

HTTPS server 里需要配置：

• listen 443 ssl；
• 证书文件路径；
• 私钥文件路径；
• SSL 协议版本；
• 前端页面 location；
• /api 后端代理；
• 静态资源访问路径。

配置完成后，就可以通过：

https://服务器IP

访问项目。

HTTPS 页面不能随便请求 HTTP 资源

当前端页面已经通过 HTTPS 打开时，页面里再请求 HTTP 后端或 HTTP 图片资源，浏览器可能会拦截。

这叫混合内容问题。

所以升级 HTTPS 时，不能只改前端页面入口，还要同步处理：

• 后端 API 地址；
• 静态资源地址；
• WebSocket 地址；
• 前端生产环境配置；
• Nginx 代理规则。

最终目标仍然是统一入口：

https://服务器IP
https://服务器IP/api
https://服务器IP/upload/...

录音功能验证

启用 HTTPS 后，可以重新验证录音相关功能。

如果浏览器提示证书不可信，需要先继续访问自签证书页面。进入页面后，再测试录音 API 是否可用。

如果仍然不可用，优先检查：

• 当前页面是不是 HTTPS；
• 前端 API 地址是不是也走 HTTPS；
• WebSocket 是否使用安全协议；
• 浏览器是否授权麦克风；
• Nginx 是否正确代理后端。

Dify 和报销审批流

报销审批不是简单的一步提交。

真实业务里，审批流会根据金额、人员层级、部门规则不断变化。

例如：

• 金额不超过某个阈值，只需要直属领导审批；
• 金额较高，需要上级经理继续审批；
• 金额超过更高阈值，需要总经理或老板审批；
• 当前审批人通过后，要判断流程是否结束；
• 如果没结束，要继续找下一个审批人。

这类流程判断，可以交给 Dify 工作流处理。

后端如何调用工作流？

后端仍然是业务系统的核心。

Dify 不直接替代业务后端，而是被后端调用。

可以这样理解：

1. 用户在前端提交报销单；
2. 后端保存报销业务数据；
3. 当前审批人操作通过；
4. 后端调用 Dify 工作流判断下一步；
5. Dify 返回是否结束、下一个审批人是谁；
6. 后端继续更新业务状态。

Dify 负责流程判断和编排，后端负责业务数据和系统状态。

LangGraph 和 Dify 都是工作流吗？

它们都可以处理“流程”，但使用场景不同。

工具	更适合的方向
LangGraph	代码级 Agent 流程、状态机、对话记忆、复杂程序控制
Dify	可视化工作流、模型调用编排、业务人员更容易理解的流程配置

当前先部署 Dify，是为了后续报销审批项目提前准备好工作流平台。