Reflex Build 应用通用设置指南：名称、ID、可见性、复用导出与删除

导读

在 Reflex Build（Reflex 的 AI 应用构建平台）中，每个应用都有一组独立于代码编辑之外的通用设置：应用名称与 ID、可见性（Private/Public）、模板保存、复制、源码下载以及永久删除。本文以 docs/ai_builder/app_lifecycle/general.md 为骨架，系统梳理这些设置的作用、操作路径与安全注意事项，并结合 Reflex 开源仓库中的配置与权限实现，帮助你在创建、共享、复用和下线应用的全生命周期中做出正确决策。

打开应用设置

在 Reflex Build 中，每个应用都有一个"更多"菜单（more menu），点击后选择 Settings 即可进入该应用的设置页。

打开应用 → 点击应用卡片/编辑器中的"更多"菜单 → 选择 Settings

Settings 页面集中管理应用本身的生命周期属性，包括基本信息、可见性、复用导出入口和删除操作，与项目的成员管理（见 Managing Project Access）相互独立：前者管"这个应用是什么、谁能看、如何复用"，后者管"谁能进入这个项目"。

基本信息：应用名称与 ID

Settings 页面的 General Information 区域展示两个核心标识：

• App Name（应用名称）：面向用户的显示名称。当应用用途发生变化时（例如从内部原型转成对外演示工具），应重命名以保持语义清晰。
• App ID（应用 ID）：应用在平台内部的唯一标识。当联系支持团队或其他 Reflex 服务时需要提供准确的应用 ID，以便对方精确定位到你的应用。

在 Reflex 开源框架中，应用名称同样是最基础的配置项。rxconfig.py 中的 app_name 字段要求与应用目录名保持一致，并且在 BaseConfig 中被声明为必填字段：

# packages/reflex-base/src/reflex_base/config.py
@dataclasses.dataclass(kw_only=True)
class BaseConfig:
    app_name: str  # 应用的名称，应与应用目录名一致

生成新应用时，rxconfig_template 会直接把应用名写入配置模板：

# packages/reflex-base/src/reflex_base/compiler/templates.py
def rxconfig_template(app_name: str):
    ...
    app_name="{app_name}",

可见，无论是 Reflex Build 中的 App ID，还是开源框架中的 app_name，应用标识都贯穿于配置、目录结构与构建流程。建议在重命名应用时同步确认 rxconfig.py 中的 app_name，保持命名一致，避免构建链路出现歧义。

可见性：Private 与 Public

App Visibility（应用可见性） 决定谁能打开这个应用：

• Private（私有）：只有拥有该项目访问权限的人可以打开应用。项目访问权限由项目成员角色控制，详见 Managing Project Access 中的成员添加、角色分配与"有效权限"查看机制。
• Public（公开）：应用可以通过只读链接（read-only link）分享给任何人，无需项目权限即可访问。

在将应用切换为 Public 之前，务必完成一次安全审查，重点检查：

• 凭据泄露：是否将 API Key、Token、数据库连接串等写死在前端代码、提示词或源码中。Reflex Build 推荐的凭据管理方式是使用 Secrets 功能，让应用在运行时通过环境变量读取，例如后端 Python 代码用 os.environ["STRIPE_SECRET_KEY"] 读取密钥，且绝不读入浏览器执行的代码（见 Secrets）。
• 私有数据：是否包含用户个人数据、内部业务数据或不应公开的样本数据。
• 未完成内容：是否存在半成品页面、调试输出、占位逻辑或临时代码。

一个从源码层面佐证"可见性必须与凭据隔离"的例子：Reflex 框架在配置层专门标记了敏感环境变量，_sensitive_env_vars 集合中的 DB_URL、ASYNC_DB_URL、REDIS_URL 不会被记录进日志：

# packages/reflex-base/src/reflex_base/config.py
# These vars are not logged because they may contain sensitive information.
_sensitive_env_vars = {"DB_URL", "ASYNC_DB_URL", "REDIS_URL"}

公开应用时请以同样的标准对待自己项目中的敏感配置，避免把私有环境变量随应用一同暴露。

复用与导出：模板、复制、下载

Settings 页面提供三个复用/导出入口，它们把"已有应用"变成可复用的起点：

• Save as a template（保存为模板）
• Copy the app（复制应用）
• Download the source（下载源码）

这三种操作都可在 Settings 中完成；同时，Deploy 按钮旁边的菜单也提供了 Copy 和 Download 的快捷入口，日常复用无需进入 Settings。

保存为模板

把应用保存为模板，可以让团队成员或整个组织直接以它为起点创建新应用。操作路径与要点：

1. 在应用 Settings 中点击 Save as Template（需要对应角色权限）。
2. 为模板起一个清晰的名称和描述，方便队友判断何时使用。
3. 保存前移除凭据、个人数据与应用专属内容，保留有代表性的示例数据和说明，让起点易于理解。

模板可以在项目级和组织级共享：项目侧边栏的 Templates 管理项目内模板，组织设置中的 Templates 管理跨组织共享的模板；新建应用时可在 Builder 的 Templates 选项卡中看到团队模板。选择结构与你目标应用最接近的模板，通常比改造一个完全无关的模板更快。完整流程见 Templates。

复制应用

Copy 从现有 Reflex Build 应用创建一个完全独立的新应用，适合在不改动原应用的前提下试验重大变更，或把可用的工作起点复用到新任务中。

复制流程：
1. 打开 Deploy 旁的菜单，选择 Copy（Settings 中也有复制入口）。
2. 等待复制后的应用在当前项目中打开。
3. 重命名新应用，使其与原应用易于区分。

复制的内容包括应用的代码、状态、配置和依赖；对副本的修改不会影响原应用。但复制后需要重新审视集成、密钥与可见性——原应用的凭据和访问要求可能需要在新副本中单独确认。另外注意 Fork 与 Copy 的差异：对他人公开应用或模板使用 Fork（会生成独立的源码副本，见 Fork App），对你自己拥有的应用使用 Copy。

下载源码

Download 生成一次性的源码导出包，用于本地开发或自托管部署。

下载流程：
1. 打开 Deploy 旁的菜单。
2. 选择 Download（应用 Settings 中同样可用）。
3. 保存并解压生成的归档文件。

归档包含应用源码、静态资源、依赖清单以及继续开发所需的 Reflex 配置。密钥、集成凭据及其他受保护的项目值不属于源码导出的可移植部分——需要在目标环境中单独配置，且绝不能提交到版本控制。

如果需要持续的版本控制，可将应用连接到 GitHub（通过 reflex-build GitHub App 创建并同步仓库，支持推送、拉取、切换分支与回滚，见 Connecting to GitHub）；如果要从已有的 GitHub、GitLab、Bitbucket、Azure DevOps 或其他 Git 仓库开始 Reflex Build 工作，则连接项目级 Project Repositories，使用 HTTPS 克隆 URL 加最小权限的 personal access token 即可。

删除应用

Delete（删除） 操作会永久移除应用，无法恢复。删除前请务必：

1. 确认选中的是正确应用（核对应用名称与 ID）。
2. 通过 Copy 或 Download 备份任何还需要的内容。
3. 检查该应用是否被其他流程引用（例如部署域名、对外链接、团队共享模板）。

结合前面的内容可以总结一个"删除前清单"：先确认可见性与共享状态，再复制或下载源码，最后执行删除。这与保存模板、公开应用前的审查逻辑一脉相承——所有不可逆或对外可见的操作，都应先完成凭据与数据的自查。

总结

应用设置是 Reflex Build 应用生命周期的"控制面板"：名称与 ID 提供唯一标识，可见性控制访问边界，模板/复制/下载承载复用与迁移，删除则是最后的收尾操作。实践中牢记三条原则：

1. 公开或分享前先审查：检查凭据、私有数据与未完成内容（配合 Secrets 管理敏感配置）。
2. 复用优于重建：模板适合组织内沉淀起点，Copy 适合自己名下应用的衍生，Fork 适合他人公开应用，Download 适合本地与自托管。
3. 删除不可逆：执行删除前，先确认应用、再备份源码。

把这些设置与项目访问权限（Managing Project Access）、部署流程（Deploy App）配合使用，即可完整覆盖应用从创建、复用、部署到下线的全过程。