在真实项目中，你很可能需要为开发、测试、生产三个环境维护不同的配置，比如 API 地址、日志级别、调试开关等。如果这些值硬编码在代码里，每次切换环境都要手动改，既容易出错，又违背了软件工程的基本原则。Tauri 本身并没有内置一套“多环境配置系统”，但它的架构为环境隔离提供了非常自然的实现路径——前端和后端可分别管理各自的配置，打包时再通过命令行参数或构建工具统一注入。
核心思路
- 前端配置：由前端构建工具（如 Vite）处理，利用
.env文件和环境变量，在不同模式下替换运行时变量。 - Rust 后端配置：通过 Tauri 配置文件（
tauri.conf.json）中的extra字段、Rust 的 feature 标记，或者运行时读取外部配置文件来区分环境。 - 统一注入：打包时通过
--target或自定义命令，把环境相关的值注入到前端资源或 Rust 二进制中。
下面通过一个完整的例子，展示如何对一个需要调用后端 API 的 Tauri 应用做三环境隔离。
1. 前端环境隔离（以 Vite + React 为例）
Vite 天然支持环境变量：根目录下的 .env、.env.development、.env.production 文件会根据运行模式自动加载。
目录结构：
src-tauri/ # Rust 后端
src/ # 前端代码
.env # 所有环境都加载的基础变量
.env.development # 开发环境，运行 pnpm tauri dev 时生效
.env.production # 生产环境，运行 pnpm tauri build 时生效.env.development：
VITE_API_BASE_URL=http://localhost:3000/api
VITE_LOG_LEVEL=debug.env.production：
VITE_API_BASE_URL=https://api.yourapp.com/v1
VITE_LOG_LEVEL=error在代码中通过 import.meta.env.VITE_API_BASE_URL 即可获取对应值。Vite 在编译时会将引用替换为实际字符串，不会产生运行时开销。
如果你还需要更多环境（如 staging），可以创建 .env.staging 并在 package.json 中增加一条脚本：
"scripts": {
"tauri:staging": "vite build --mode staging && tauri build"
}这样前端就能区分测试环境和生产环境。
2. Rust 后端环境隔离
Rust 后端是编译型语言，注入环境变量有几种实用方式：
方式一：通过 tauri.conf.json 的 extra 字段（推荐）
在 tauri.conf.json 中增加自定义配置，Tauri 会在运行时把 extra 解析为 JSON，可在 Rust 代码中直接访问。
开发时的 tauri.conf.json（或通过合并 tauri.conf.dev.json）：
{
"build": {
"devUrl": "http://localhost:5173",
"frontendDist": "../dist"
},
"extra": {
"apiBaseUrl": "http://localhost:3000/api",
"logLevel": "debug"
}
}tauri.conf.production.json：
{
"extra": {
"apiBaseUrl": "https://api.yourapp.com/v1",
"logLevel": "error"
}
}在 Rust 中通过 Tauri 的配置管理器读取（Tauri 2.0 API）：
use tauri::Manager;
#[tauri::command]
fn get_api_base_url(app: tauri::AppHandle) -> String {
let config = app.config();
let extra = config.extra.clone(); // 返回 serde_json::Value
extra["apiBaseUrl"].as_str().unwrap_or("").to_string()
}怎么让不同环境使用不同的 tauri.conf.json？
可以使用 --config 参数指定配置文件，或者利用 Tauri CLI 的配置文件合并机制（将 base 配置和环境特定配置分开）。简单做法是 在 tauri.conf.json 中保留通用配置，环境差异部分放在单独的 JSON 文件中，构建时用脚本合并或直接用 --config 指定。
更工程化的做法：构建脚本动态写入
在 build.rs 或打包前的 Node 脚本中，根据 TAURI_ENV 环境变量生成一个 Rust 文件，包含所需常量，然后在主程序中引用。这样可以做到编译时注入，不会在最终二进制中留下任何多余代码。
方式二：运行时读取环境变量或外部配置文件
如果应用需要在同一个安装包中切换环境（比如留给运维人员一个配置入口），可以运行时读取可执行文件旁边的 config.json 或系统环境变量。这在企业级应用里很常见。
use std::fs;
fn load_api_base_url() -> String {
if let Ok(content) = fs::read_to_string("app_config.json") {
// 按需解析 JSON
// ...
}
// 否则回退到默认值
"http://localhost:3000/api".to_string()
}但需要注意，Tauri 2.0 默认将资源文件打包进二进制，要读取外部文件需要调整 tauri.conf.json 中 bundle > resources 或使用 tauri::api::path 来定位配置路径。
3. 开发、测试、生产三个环境的典型配置
| 项目 | 开发（dev） | 测试（staging） | 生产（prod） |
|------|-------------|-----------------|--------------|
| 前端 API 地址 | localhost:3000 | staging-api.example.com | api.example.com |
| 后端 Rust 日志级别 | debug | info | warn 或 error |
| 应用内调试工具条 | 显示 | 显示（可隐藏） | 始终隐藏 |
| 更新检查地址 | 本地 | 测试更新服务器 | 生产更新服务器 |
| WebView devtools | 开启 | 关闭 | 关闭 |
前端的差异靠 .env.* 文件解决；后端的差异靠配置文件合并或命令行参数注入。
4. 用命令行参数统一控制环境
我们在 package.json 中定义三套命令，同时在 tauri build 时传入环境变量。
{
"scripts": {
"tauri:dev": "tauri dev",
"tauri:build:staging": "TAURI_ENV=staging vite build --mode staging && tauri build",
"tauri:build:prod": "TAURI_ENV=production vite build --mode production && tauri build"
}
}然后在 tauri.conf.json 中，如果使用 --config 参数，可以这样改造：
"scripts": {
"tauri:build:staging": "tauri build --config tauri.staging.conf.json",
"tauri:build:prod": "tauri build --config tauri.prod.conf.json"
}每个配置文件重写 extra 字段即可。
5. 实际项目中的注意事项
- 不要将敏感信息（如 API 密钥）硬编码在前端代码或配置中。生产环境密钥应通过后端安全处理，或使用 OAuth 等动态认证。
- Rust 代码中避免根据
debug!宏的展开与否决定业务逻辑。日志级别通过配置控制，但核心功能分支不应只依赖编译 flag。 - 尽量让同一个构建产物能在不同环境运行——也就是说，最好把环境差异放在配置文件或启动参数里，而不是编译时写死。这样你只需构建一次，就能派发给测试人员或直接上线，极大减少因为二次打包引入的 bug。
- 如果应用需要更新，环境配置可能影响更新服务器的地址，务必保证配置一致性，避免出现“测试环境的应用跑去生产更新服务器”的情况。
总结
Tauri 的多环境配置方案完全基于你熟悉的 web 前端和 Rust 生态，不存在黑魔法。你只需要：
- 前端靠 Vite 的
.env和环境变量； - 后端靠 Tauri 的
extra配置和 Rust 代码读取； - 通过命令行参数或不同
tauri.conf.json文件在打包时切换环境。
这套方法清晰、可控，能很好地融入团队现有的 CI/CD 流水线，让应用在开发、测试和生产三个环节中安全平稳地运行。