Profile 到底是什么：它不是用户配置，而是产品的交付策略

产品策略决定交付边界；用户设置决定个人使用体验。两者都叫“配置”，但不该由同一个人、在同一个时刻改。

最近在梳理一个轻量化浏览器 Runtime 的方案时，团队里冒出了一个很自然的问题：Lean Distribution Profile 里的 Profile，是不是用户配置？

不是。

这里的 Profile 指的是 Distribution Profile：一个产品发行版的交付策略。它由产品和工程团队维护，随构建和安装包一起生效；用户在设置页里看到的主题、首页、语言、隐私开关，则属于另一类东西：User Settings。

名字相近，边界却不能含糊。把它们泡在一起，最后很容易出现两种问题：要么把产品级决策暴露成用户开关，要么在升级时意外覆盖用户的个人偏好。

一句话总结

Distribution Profile 是“我们交付哪一种产品”的配置；User Settings 是“我怎样使用这一个产品”的配置。

前者发生在构建、打包、签名、更新之前；后者发生在安装之后，属于用户的长期数据。

1
2
3
4
5

Distribution Profile
  → Stage / Package / Release
  → 已安装的 App
  → User Settings
  → 每个人自己的使用体验

这条顺序也说明了一个关键事实：Distribution Profile 可以提供默认值和能力边界，但它不应该替代用户偏好。

两种 Profile，服务两种完全不同的决策

在 Chromium 语境里，Profile 还是一个高频词，通常表示承载 Cookie、扩展、历史记录和偏好的用户资料目录。这会让术语更容易混乱。

我倾向于把它们拆成下面三类，再讨论具体设计：

这三个对象都可以被称作“配置”，但它们的生命周期不同。

用户改深色模式，不应该触发一次重新打包；产品把 macOS Runtime 从标准策略切换到 Lean 策略，也不应该等用户去设置页勾选。前者需要保存在用户数据中，后者需要经过构建、测试、灰度和回退。

Distribution Profile 到底放什么

把它理解成“安装包的菜单”并不准确，它更像产品交付时的一份约束声明：这次发行版允许哪些能力、选择哪些已验证的实现，以及在什么平台上采用什么策略。

一个抽象的例子可能长这样：

1
2
3
4
5
6
7
8
9
10
11

{
  "product": "vertical-browser",
  "runtime": {
    "package": "approved-runtime",
    "targets": ["darwin-arm64"]
  },
  "platformPolicy": {
    "macos": "lean"
  },
  "updateChannel": "stable"
}

它描述的是发布者要交付什么，不是让用户从 lean 和 standard 之间自己选择。真正的字段、校验和包名当然要跟着项目契约走；这里更重要的是职责：Profile 选择经过验证的产物和策略，Build Kit 再把它们组装成可交付的应用。

这样做有一个直接收益：产品线可以共享内核、构建工具和契约，却仍然保持独立身份、Runtime 选择和更新节奏。它不会把某一个发行版的偏好写死到通用内核里。

Lean Profile 不是一个新进程

Lean Distribution Profile 这个名字也很容易造成第二层误解：仿佛 Profile 本身会常驻、代理请求，或者在运行时“偷偷优化”资源。

它不会。

Profile 只是声明“macOS 这次要采用 Lean 策略”。如果这项策略需要一个 Runtime Adapter，Adapter 才是实际的可执行产物；Profile 只是让构建和打包流程选择它。运行时调用链仍然应该保持清楚：

1
2
3
4
5

Build time
Distribution Profile → 选择 macOS Lean Runtime Adapter → 安装包

Runtime
Browser → 已选定的 Adapter / Runtime → 既有服务契约

这个拆法很重要。优化的实现可以迭代，Profile 作为选择点保持稳定；用户数据、浏览器核心和既有 Runtime 契约不必为了一个发行策略被直接改写。

为什么不直接给用户一个“省资源模式”开关

从体验上看，这个开关似乎很合理：想省内存就打开，想快一点就关闭。但如果“省资源”改变的是后台 Runtime 的启动时机、健康检查、失败重试或服务端口，那么它已经不是纯偏好，而是可靠性策略。

可靠性策略交给每个用户自由切换，代价通常是不可复现：同一个崩溃、首请求超时或更新问题，工程团队首先要问“你当时开的是哪一种模式”。更糟的是，用户可能在需要稳定执行任务时误切到了实验策略。

我的判断是：

• 外观和交互偏好，交给 User Settings；
• 已经验证稳定、且可被安全回退的平台资源策略，交给 Distribution Profile；
• 仍在试验、需要大量观测的策略，先留在开发或灰度流程里，不急着变成用户开关。

这不是反对可配置，而是让配置落在正确的所有权和验证链条上。

轻量化的第一原则：先守住契约，再减少常驻成本

对于垂类浏览器，减少不需要的能力、资源和常驻工作，确实可能比通用浏览器更轻。但“按需启动”不是天然等于更稳定，也不是天然等于更省。

它至少会引入首请求延迟、并发启动、健康状态、失败重试、升级后兼容等新状态。因此更稳妥的路径不是一开始就做激进裁剪，而是把目标拆开：

1. 先测量安装包、内存和 CPU 的主要来源；
2. 先移除明确无用、且不触碰产品契约的资源；
3. 对按需启动这类策略，先做单次启动保护、就绪判定、超时和回退；
4. 在 macOS 的独立 Profile 中灰度验证，Windows 保持既有策略，等证据足够再单独决策。

这里的核心不是“用 Profile 把优化开关藏起来”，而是让每一项优化都有明确的适用平台、验收标准和撤回路径。稳定性优先时，Profile 是护栏，不是加速器。

要不要用 / 我的判断框架

当一个配置决定的是产品交付的身份、能力集合、Runtime 或平台运行策略，它应该属于 Distribution Profile，并进入版本控制、构建校验和发布验收。

当一个配置决定的是某个人如何使用已经安装的产品，它应该属于 User Settings 或浏览器用户资料，并在更新后保持不变。

如果两边都说得通，先问一个简单的问题：这个开关切换后，是否需要工程团队重新验证启动、升级、回退和故障恢复？如果需要，它大概率不是用户配置。

把这条边界立住以后，Lean Distribution Profile 就不再是一个模糊的新概念。它只是产品在 macOS 上选择一条经过验证的、可回退的轻量交付路径；用户仍然拥有自己的浏览器和偏好，工程团队则对产品的可靠性负责。