M1 运行时热换皮 · 技术验证 Demo

验证路径

1. 打开管理台，改产品名 / logo / 图标 / 主色 / 登录页文案 / 客服联系方式
2. 点「保存并发布」 —— 服务端写入新版本并用 Ed25519 私钥签名
3. 终端客户预览会实时变化（注入层品牌，与客户端内的页面品牌同一套逻辑）
4. 启动 Electron 客户端：拉 bootstrap → 验签 → 应用品牌（窗口标题 / 图标 / 托盘 / 菜单 / 页面内品牌）
5. 再次改品牌并重启客户端，验证是「热换皮」而非「重打包」

进入品牌管理台 → 查看 bootstrap 接口

这个 Demo 覆盖了规格里的哪些关键点

配置下发

GET /api/client/bootstrap（启动）+ /api/client/heartbeat（心跳比对版本）

防篡改

Ed25519 签名，服务端自校验，客户端持公钥验签

两段式发布

草稿 → published，版本号单调递增

粘性降级

客户端持久化最后一次成功配置；拉取失败用缓存，绝不回落到平台默认品牌

审计

brand_config_fetch 记录每次拉取的客户端、版本、IP、UA

热更新

心跳发现新版本 → 提示「重启以应用新品牌」

白标边界

名称、logo、图标、主色、客服联系方式可改；协议主体与合规声明不可改

为什么这件事值得做成技术规格

竞品调研结论：闭源客服 SaaS 一律把白标收进企业合同或书面拒绝；A 层头部指纹浏览器厂商的公开白标能力基本为零；唯一公开可证实「私有化 + 客户端换名换图标」的是 flowglot——而它的品牌名硬编码在安装包文件名与 .app bundle 里，换名需重打包重签名。

也就是说，行业标准是「重打包」，每新增一个渠道商就多一次排期与一次签名交付。

我们要把它变成「配置」：一次性工程投入，之后每个渠道商换牌的边际成本≈0。这是从「卖产品」升级为「卖渠道能力」的技术前提。

完整规格见《05-运行时热换皮技术规格》，本 Demo 只实现最小可验证切片。

目录说明

server/

Next.js 管理台 + API + Postgres（brand_config 等 4 张表）

server-lite/

零框架依赖的降级版服务端（Next.js 装不动时用这个）

client/

Electron 客户端：启动拉配置 → 验签 → 换皮 → 自截图