当前位置：首页 > news >正文

Dioxus 应用怎么打包发布：Web、桌面、移动三端全流程

news 2026/7/1 19:10:58

前言

我一直觉得，Dioxus 这种框架最容易让人上头的地方，不是语法，而是那种错觉。

你前面已经把一套 Rust 代码在 Web、桌面、移动上都跑通了，信心会特别足。列表能出来，详情能跳，Server Functions 能调，SQLite 也能落库。这个时候很容易顺手说一句：

“差不多了，剩下就是打包。”

问题就在这里。

真正把应用交到别人手上时，事情从来不是“打包一下”这么轻。

Web 版要不要单独部署静态资源和服务端？
桌面版能不能直接发一个压缩包，还是必须做成.dmg、.msi、.AppImage？
移动端是能跑，还是能装，还是能过商店？
你在本地跑得好好的，到了容器、CI、签名、公证、分发，一堆细节会不会一起翻脸？

我自己对这件事的判断很简单：

交付不是最后一步，交付是把架构边界重新确认一遍。

因为一旦你要发布，之前很多“先这样写也能跑”的设计，都会被现实重新审判一次。

一、先把话说透：Dioxus 的“发布”不是一个动作，而是三条链路

Dioxus 官方 0.7.0 的 fullstack 文档已经把一件事说得很直白了：一个 fullstack 应用至少由两部分组成。

客户端 binary，跑 Web、桌面或移动
服务端 binary，负责首屏和 Server Functions

这句话很重要。它意味着 Dioxus 的发布不是“把整个项目塞进一个包里”那么简单，而是要分别处理：

客户端怎么交付
服务端怎么部署
两者怎么在生产环境里重新连起来

所以我更愿意把这篇拆成三块看：

Web：把public和server分开交付
Desktop：把当前平台的安装包做出来
Mobile：把 Android / iOS 的构建、签名、分发流程接上

二、Web 部署：别只盯着静态资源，Server binary 也要一起交

这是 Dioxus 发布里最容易被误解的地方。

很多人看到dx bundle --web，第一反应是：

哦，生成一个前端静态站点就完了。

实际上不是。

按官方文档，dx bundle --web --release之后，你会拿到两样东西：

public目录，里面是 HTML、JS、WASM 和资源
serverbinary，负责 Server Functions 和服务端逻辑

这就决定了 Web 版的交付方式，不是“上传一个前端目录”，而是“前端资源 + 服务端程序”一起上。

2.1 最小可用流程

先把 bundle 产物做出来：

dx bundle--web--release

然后你会得到类似这样的结构：

target/dx/your-app/release/web/ ├── public/ │ ├── index.html │ ├── assets/ │ └── wasm/ └── server

这里的关键不是目录长什么样，而是职责分得很清楚：

public给静态资源服务器或 CDN
server给运行时

如果你的应用根本没用 Server Functions，Web 版会简单很多。但只要用了全栈能力，就不能假装只有前端。

2.2 Docker 部署最实在

我对 Dioxus Web 部署的推荐顺序很简单：

先本地跑通
再容器化
最后再考虑 CDN 和反向代理优化

一个很朴素的 Dockerfile 大概长这样：

FROM rust:1.78 AS builder WORKDIR /app COPY . . RUN cargo install dioxus-cli RUN dx bundle --web --release FROM debian:stable-slim WORKDIR /usr/local/app COPY --from=builder /app/target/dx/your-app/release/web /usr/local/app ENV IP=0.0.0.0 ENV PORT=8080 EXPOSE 8080 ENTRYPOINT ["/usr/local/app/server"]

这里有两个细节值得单独说。

第一，server不能丢。很多人只拷public，结果页面能打开，接口全挂，这种问题很像“部署成功，功能失败”。

第二，容器里要把监听地址改成0.0.0.0。官方文档明确提到，默认只监听本地回环地址的话，容器外面是访问不到的。