我的文档库基于 Cloudflare Workers 构建后台管理 BFF：认证、权限、R2 与配置中心设计
本文介绍基于 Cloudflare Workers+R2 搭建管理 BFF，作为管理 SPA 统一控制层。实现登录会话、资源‑动作权限校验，R2 存储配置、审计、用户数据，支持配置热更新、数据同步、文件上传，采用加密签名与时间戳做请求防护；指出 R2 并发写入等局限，规划架构演进，适配低频内部后台场景。
一、背景
在前端管理系统中，除了页面本身，还通常需要一层面向管理端的服务，用于承载：
- 管理员登录与身份认证
- 用户与权限管理
- 对象存储数据查询
- 业务数据同步
- 运行时配置管理
- 审计日志
- 文件上传
- 性能监控数据查询
如果管理端直接访问多个后端服务，前端不仅需要处理不同服务的认证方式、接口协议和跨域问题，还容易将大量基础设施细节暴露给浏览器。
因此，可以在管理 SPA 与底层基础设施之间增加一层轻量级 BFF（Backend For Frontend）。
本文介绍一种基于 Cloudflare Workers + R2 实现管理 BFF 的方案，将认证、权限、数据访问和管理能力统一收敛到一个边缘服务中。
整体架构如下：
┌─────────────────────┐
│ Admin SPA │
│ 管理后台前端应用 │
└──────────┬──────────┘
│ HTTPS
▼
┌─────────────────────┐
│ Cloudflare Worker │
│ Admin BFF │
├─────────────────────┤
│ Authentication │
│ Authorization │
│ API Router │
│ Encryption │
│ Audit │
└───────┬──────┬──────┘
│ │
┌────────────┘ └──────────────┐
▼ ▼
┌──────────────┐ ┌──────────────┐
│ Cloudflare │ │ External API │
│ R2 │ │ / Services │
└──────────────┘ └──────────────┘
│
▼
┌──────────────┐
│ Other Worker │
│ / Monitor │
└──────────────┘BFF 不负责承载复杂业务逻辑，而是作为管理端的统一控制入口。
二、设计目标
整个服务主要解决以下问题。
2.1 统一管理入口
管理 SPA 不直接访问 R2、外部业务 API 或其他 Worker，而是统一请求：
Admin SPA
│
▼
Admin BFF
│
├── Account
├── R2
├── Sync
├── Config
├── Audit
├── Upload
└── Monitor这样可以将底层基础设施与管理端 UI 解耦。
2.2 统一认证与权限控制
所有管理 API 通过统一 Session 进行身份认证，并在服务端执行权限校验。
权限模型采用：
用户
│
├── users
│ ├── read
│ ├── edit
│ └── ...
│
├── cache
│ ├── read
│ └── ...
│
├── sync
│
├── worker-config
│ ├── read
│ └── edit
│
├── audit
│
├── upload
│ └── edit
│
└── monitor
├── read
└── edit权限不仅用于控制前端菜单，同时必须在 Worker API 层再次校验。
前端隐藏按钮只是 UI 行为，不能作为真正的权限边界。
2.3 管理配置无需重新部署
对于需要频繁调整的运行时配置，不应该每次修改都重新部署 Worker。
因此将配置持久化到 R2：
Admin SPA
│
│ 修改配置
▼
Admin BFF
│
▼
R2
/configs/{worker}.json
│
│ 定期读取
▼
Runtime Worker运行时 Worker 使用短 TTL 缓存配置，在配置修改后可以较快生效。
2.4 统一审计
管理后台涉及账号、配置、数据同步等高价值操作，需要保留操作记录。
因此所有关键写操作都记录：
operator
timestamp
action
resource
detail审计数据最终持久化到 R2。
三、整体模块设计
后台 BFF 可以按照业务能力划分为以下模块：
| 模块 | 主要职责 |
|---|---|
| Authentication | 登录、Session、密码管理 |
| Authorization | 权限校验 |
| Cache | R2 对象查询 |
| Sync | 外部 API → R2 数据同步 |
| Worker Config | Worker 运行时配置 |
| Audit | 管理操作审计 |
| Upload | 文件上传 |
| Monitor | 性能监控配置与指标查询 |
| Crypto | 请求加密与签名 |
| Response | CORS 与统一响应 |
推荐的代码组织方式：
src/
├── index.ts
│
├── routes/
│ ├── admin.ts
│ ├── cache.ts
│ ├── sync.ts
│ ├── worker-config.ts
│ ├── audit.ts
│ ├── upload.ts
│ └── monitor.ts
│
└── lib/
├── crypto.ts
├── audit.ts
└── response.ts这种结构的核心不是目录本身，而是将：
Route
↓
Authorization
↓
Business Operation
↓
Storage / External API
↓
Audit形成清晰的调用边界。
四、认证体系设计
4.1 登录流程
登录请求链路：
┌───────────┐
│ Admin SPA │
└─────┬─────┘
│
│ email + password
▼
┌────────────────────┐
│ AES-256-GCM Encrypt│
└─────────┬──────────┘
│
│ POST /api/admin/login
▼
┌────────────────────┐
│ Admin Worker │
├────────────────────┤
│ decrypt │
│ password verify │
│ create session │
└─────────┬──────────┘
│
▼
Session Token客户端首先对登录数据进行加密：
{
"email": "user@example.com",
"password": "********"
}Worker 收到请求后：
- 验证请求格式
- 解密请求体
- 根据账号查询用户
- 验证密码哈希
- 创建 Session
- 返回 Session Token
后续请求携带 Session Token：
Admin SPA
│
│ Authorization / Session
▼
Admin Worker
│
├── Verify Session
│
├── Load Permission
│
└── Execute API五、密码存储
密码不能以明文形式存储。
用户数据中只保存密码哈希：
{
"email": "user@example.com",
"passwordHash": "..."
}认证过程：
用户密码
│
▼
Password Hash
│
▼
与存储值比较当前方案支持使用 PBKDF2 或 SHA-256 进行密码哈希。
对于正式生产系统，更推荐使用专门设计的密码派生算法，并结合：
- 随机 Salt
- 足够的计算成本
- 密码策略
- 登录失败限制
来提高离线破解成本。
六、Session 设计
登录成功后，服务端生成 Session Token。
后续请求：
POST /api/admin/verify用于验证：
Session
│
├── 是否存在
├── 是否有效
├── 是否过期
└── 用户身份验证成功后返回当前权限信息。
这里有一个重要设计点：
权限应该在服务端校验，而不是信任客户端保存的权限状态。
前端可以缓存权限用于渲染菜单，但 API 是否允许执行某个操作，必须由 Worker 决定。
七、权限模型
管理系统可以采用：
Resource + Action的方式表达权限。
例如：
users.read
users.edit
cache.read
sync.execute
worker-config.read
worker-config.edit
audit.read
upload.edit
monitor.read
monitor.editAPI 执行流程：
Request
│
▼
Authentication
│
▼
Load User
│
▼
Check Permission
│
├── No → 403
│
└── Yes
│
▼
Execute这种设计相比直接在代码中写大量：
if (user.role === "admin")更加容易扩展。
八、R2 作为管理数据存储
Cloudflare R2 不仅可以存储静态资源，也可以作为轻量级管理数据存储。
本方案主要使用 R2 存储：
R2
├── users
│ └── user.jsonl
│
├── configs
│ └── {worker}.json
│
├── audit
│ └── audit.jsonl
│
├── static
│ └── images...
│
└── metrics
└── performance...不同数据采用不同存储方式。
| 数据 | 存储方式 |
|---|---|
| 用户 | JSONL |
| 审计 | JSONL |
| Worker 配置 | JSON |
| 图片 | Object |
| 性能指标 | JSON |
| 缓存数据 | Object |
这种方式比较适合：
- 数据规模较小
- 写入频率较低
- 主要由管理端访问
- 不需要复杂 SQL 查询
的后台系统。
九、Worker 配置中心
9.1 为什么需要运行时配置
如果直接使用：
Worker Environment Variables修改配置通常需要重新部署。
对于灰度比例、性能阈值、采样周期等经常变化的参数，这种方式成本较高。
因此将配置拆成两层：
Config
│
┌────────┴────────┐
▼ ▼
R2 Runtime Config Worker Env
Primary FallbackR2 配置优先。
如果 R2 中不存在，则回退到 Worker 环境变量。
9.2 配置读取
例如：
POST /api/worker-config/read服务端：
Request
│
▼
Load R2 config
│
├── Exists → return
│
└── Missing
│
▼
Worker Env9.3 配置写入
修改配置：
POST /api/worker-config/write流程：
Admin
│
│ encrypted request
▼
Worker
│
├── Authentication
├── Authorization
├── Validation
│
▼
R2
│
▼
Audit运行时 Worker 定期读取 R2 配置，并通过短 TTL 缓存减少 R2 请求。
因此可以实现：
修改配置
↓
R2
↓
短时间内被 Runtime Worker 读取
↓
配置生效无需重新部署 Worker。
十、配置热更新的一致性
配置热更新并不意味着“实时一致”。
实际模型更接近：
R2
│
│ read
▼
Worker Cache
│
│ TTL
▼
Runtime因此需要明确：
配置修改后，系统允许存在一个有限的传播延迟窗口。
例如缓存 TTL 为 10 秒，则通常可以将配置生效时间控制在这一量级。
这种设计在配置中心中属于典型的：
最终一致性 + 短 TTL 缓存
模型。
十一、数据同步
管理后台还可以提供数据同步能力。
基本流程：
┌──────────────┐
│ External API │
└──────┬───────┘
│
│ fetch
▼
┌──────────────┐
│ Admin Worker │
└──────┬───────┘
│
│ transform
▼
┌──────────────┐
│ R2 │
└──────┬───────┘
│
▼
Frontend同步任务可以统一抽象：
POST /api/sync/{taskName}例如：
sync/machines
sync/vip
sync/configWorker 根据任务名选择对应的数据源。
11.1 为什么通过 Worker 同步
直接让浏览器请求外部 API 会遇到：
- CORS
- 外部 API 地址暴露
- 认证信息管理
- 不同环境 API 地址差异
- 前端数据结构与后端数据结构耦合
通过 Worker 统一同步后：
External API
│
▼
Worker
│
▼
R2
│
▼
Frontend前端只需要访问统一的数据源。
十二、同步任务与审计
同步任务不是普通查询操作，而是具有副作用的管理操作。
因此执行成功后记录审计：
{
"operator": "user@example.com",
"timestamp": 1710000000000,
"action": "sync",
"resource": "machines"
}完整链路：
Trigger Sync
│
▼
Authorization
│
▼
External API
│
▼
Transform
│
▼
R2
│
▼
Audit这样可以回答：
- 谁执行了同步？
- 什么时间执行？
- 同步了什么数据？
- 是否执行成功？
十三、审计日志
13.1 JSONL
审计日志采用 JSONL：
{...}
{...}
{...}
{...}每一行表示一条独立事件。
例如：
{
"operator": "user@example.com",
"timestamp": 1710000000000,
"action": "worker-config.update",
"resource": "worker-a",
"detail": {
"changed": ["interval", "threshold"]
}
}JSONL 的优点是：
- 追加写入简单
- 单条记录独立
- 结构清晰
- 方便后续迁移到其他日志系统
13.2 当前查询策略
在低频管理后台场景下，可以：
R2
│
▼
Read JSONL
│
▼
Parse
│
▼
Memory Pagination这种方式实现简单，适用于操作量较低的管理系统。
但是随着日志增长，全量读取的成本会逐渐增加。
因此需要提前定义演进路线：
audit.jsonl
│
▼
按日期拆分
│
▼
audit/2026/09/16.jsonl
│
▼
索引 / 专用日志系统十四、文件上传
文件上传接口：
POST /api/upload采用：
multipart/form-data基本流程：
Browser
│
│ multipart
▼
Worker
│
├── Permission
├── File Type
├── File Size
│
▼
R2
│
▼
Object URL当前方案限制单个文件大小为 5MB。
文件存储在独立的静态资源目录下：
static/
├── image-a.webp
├── image-b.png
└── ...生产环境中还应该进一步考虑：
- 文件类型校验
- 文件名规范化
- Object Key 随机化
- Content-Type 设置
- 缓存策略
- 重复文件处理
- 图片尺寸限制
十五、统一加密请求
对于管理端写操作，请求体采用：
{
"p": "<encrypted payload>",
"s": "<signature>",
"t": 1710000000000
}其中：
| 字段 | 含义 |
|---|---|
p | AES-256-GCM 密文 |
s | HMAC-SHA256 签名 |
t | 请求时间戳 |
十六、AES-256-GCM
请求数据首先使用 AES-256-GCM 加密。
典型结构：
Plaintext
│
▼
AES-256-GCM
│
├── Random Nonce
│
▼
Ciphertext当前方案使用随机 12 字节 Nonce，并将 Nonce 与密文一起传输。
AES-GCM 同时提供：
- 数据机密性
- 完整性校验
十七、HMAC-SHA256
在加密数据基础上，再使用 HMAC-SHA256 生成签名：
Ciphertext
│
▼
HMAC-SHA256
│
▼
SignatureWorker 收到请求后：
Request
│
├── Verify timestamp
│
├── Verify HMAC
│
└── Decrypt AES-GCM
│
▼
Payload这样可以进一步防止请求密文被篡改。
十八、需要明确的安全边界
这里有一个非常重要的安全问题：
如果 AES 加密密钥同时存在于浏览器端，那么这个密钥并不是严格意义上的服务端秘密。
因为浏览器中的：
VITE_*
NEXT_PUBLIC_*等构建时变量最终可能被用户获取。
因此：
HTTPS
+
Request Encryption
+
HMAC
+
Session Authentication并不等价于：
真正的端到端安全密钥体系这套设计更适合用于：
- 增加请求数据保护
- 防止普通中间层直接读取明文
- 防止请求内容被简单篡改
- 配合 HTTPS 增强管理接口安全性
如果系统属于高安全等级场景，应考虑将真正的密钥只保留在服务端，并采用更成熟的认证与密钥管理体系。
十九、时间戳与重放保护
请求中的：
{
"t": 1710000000000
}可以用于增加请求时效性校验。
服务端可以检查：
abs(serverTime - requestTime) <= allowedWindow超过窗口则拒绝请求。
这样可以降低旧请求被重复提交的风险。
完整请求验证：
Request
│
▼
Timestamp Check
│
▼
Signature Check
│
▼
Decrypt
│
▼
Session Check
│
▼
Permission Check
│
▼
Business Logic二十、CORS
由于 Admin SPA 与 Worker 可能部署在不同域名，因此 Worker 需要统一处理 CORS。
预检请求：
OPTIONS /api/...直接返回允许的 CORS Header。
生产环境不应该使用：
Access-Control-Allow-Origin: *而应该限制到实际管理后台域名。
例如：
Admin SPA
│
│ HTTPS
▼
Worker
│
└── Access-Control-Allow-Origin
│
└── Admin Origin这样可以缩小管理 API 的跨域暴露范围。
二十一、API 设计
管理 API 按领域进行划分。
Health
GET /health用于健康检查。
Authentication
POST /api/admin/login
POST /api/admin/verify
POST /api/admin/change-passwordUser Management
GET /api/admin/accounts
POST /api/admin/users
POST /api/admin/users/update
POST /api/admin/users/delete
POST /api/admin/users/reset-passwordR2 Cache
GET /api/cache
GET /api/cache/:key
GET /api/cache/:key/body支持：
prefix
limit
cursor等参数。
Data Sync
POST /api/sync/:taskNameWorker Config
POST /api/worker-config/read
POST /api/worker-config/writeAudit
GET /api/audit/logs
POST /api/audit/logUpload
POST /api/uploadMonitor
GET /api/monitor/config
POST /api/monitor/config
GET /api/monitor/metrics二十二、统一请求处理链
整个 API 可以统一采用如下 Middleware Pipeline：
HTTP Request
│
▼
┌───────────────┐
│ CORS / OPTIONS│
└───────┬───────┘
│
▼
┌───────────────┐
│ Route Matching│
└───────┬───────┘
│
▼
┌───────────────┐
│ Authentication│
└───────┬───────┘
│
▼
┌───────────────┐
│ Authorization │
└───────┬───────┘
│
▼
┌───────────────┐
│ Input Validate│
└───────┬───────┘
│
▼
┌───────────────┐
│ Business Logic│
└───────┬───────┘
│
┌──────┴──────┐
▼ ▼
R2 External API
│ │
└──────┬──────┘
▼
Audit
│
▼
HTTP Response这样的处理顺序可以避免每个 Route 自己重复实现认证、权限和错误处理。
二十三、错误处理
建议统一 API 错误结构：
{
"code": "FORBIDDEN",
"message": "Permission denied"
}常见 HTTP 状态：
| 状态码 | 场景 |
|---|---|
| 200 | 请求成功 |
| 400 | 参数错误 |
| 401 | 未认证 |
| 403 | 无权限 |
| 404 | 资源不存在 |
| 409 | 状态冲突 |
| 413 | 文件过大 |
| 500 | 服务端错误 |
| 502 | 外部服务异常 |
统一错误结构可以让 Admin SPA 不需要针对每个接口实现不同的异常解析逻辑。
二十四、关键操作的审计边界
并不是所有 GET 请求都需要写审计。
更合理的方式是重点记录具有副作用的操作：
登录
密码修改
用户创建
用户删除
权限修改
配置修改
数据同步
文件上传
监控配置修改例如：
User Update
│
├── DB / R2 Update
│
└── Audit Log这样可以控制审计日志增长，同时保证关键管理行为可追溯。
二十五、数据一致性问题
R2 是对象存储，而不是传统关系型数据库。
因此在使用 R2 保存 JSON / JSONL 管理数据时，需要特别注意并发写入。
例如：
Request A ── read ── modify ── write
Request B ── read ── modify ── write可能出现：
A write
↓
B write
↓
A 的修改丢失对于低并发后台管理场景，这种情况发生概率较低，但随着系统规模增长，需要进一步演进。
可选方案包括：
R2
+
Object Version / ETag
+
Optimistic Lock或者将需要高并发事务能力的数据迁移到：
D1 / PostgreSQL / Other Database而 R2 继续承担：
文件
配置快照
日志
指标
缓存等对象型数据。
二十六、当前方案的适用范围
这种 Cloudflare Workers + R2 的管理 BFF 特别适合：
- 内部运营后台
- 配置管理平台
- 数据同步控制台
- 轻量级 CMS
- CDN / Edge 管理工具
- 性能监控管理后台
- 低频管理型 API
它的优势在于：
无需维护独立服务器
+
全球 Edge Runtime
+
R2 原生集成
+
部署简单
+
成本较低但它并不是所有场景的最佳数据库后端。
当系统出现：
- 高并发写入
- 复杂事务
- 多条件查询
- 大量关系数据
- 强一致性要求
时，应将核心业务数据迁移到更适合事务处理的数据库。
二十七、测试策略
测试重点应该围绕“权限边界 + 数据一致性 + 基础设施异常”展开。
认证
✓ 正确账号密码
✓ 错误密码
✓ 不存在账号
✓ Session 验证
✓ Session 过期
✓ 非法 Session权限
✓ read 权限
✓ edit 权限
✓ 无权限 → 403
✓ Root 权限
✓ 用户删除权限
✓ 配置修改权限加密
✓ AES-GCM 加解密
✓ Nonce 随机性
✓ HMAC 校验
✓ 密文篡改
✓ 时间戳过期R2
✓ Object 不存在
✓ Object 读取
✓ Object 写入
✓ 配置 fallback
✓ 并发更新同步
✓ 外部 API 正常
✓ 外部 API 失败
✓ 返回非 2xx
✓ 数据转换失败
✓ 同步成功后审计Upload
✓ multipart
✓ 正常文件
✓ 超过大小限制
✓ 非法文件类型
✓ R2 写入失败CORS
✓ OPTIONS
✓ 正常跨域请求
✓ 非法 Origin二十八、部署模型
Cloudflare Workers 的部署流程可以保持简单：
Source Code
│
▼
Build
│
▼
wrangler deploy
│
▼
Cloudflare Workers
│
├── R2 Binding
├── Environment Variables
└── Secrets部署前需要准备：
R2 Bucket
Worker Secrets
Runtime Configuration
Admin SPA API Endpoint其中真正敏感的凭据应该使用 Cloudflare Worker Secrets，而不是直接写入代码或普通配置文件。
二十九、配置分层
整个系统可以将配置划分为三类：
Configuration
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Build-time Runtime Secret
Config Config Config
│ │ │
▼ ▼ ▼
Frontend R2 Worker Secret例如：
Build-time
API Base URL
Application NameRuntime
Sampling Interval
Performance Threshold
Worker ConfigSecret
Encryption Secret
External API Credential
Cloudflare API Token这样可以避免把所有配置混在一起。
三十、风险与限制
30.1 浏览器端加密密钥
如果加密密钥需要出现在前端，则无法把它视为真正的服务端秘密。
因此当前方案的安全边界仍然依赖：
HTTPS
+
Session Authentication
+
Server-side Authorization30.2 审计日志增长
单个 JSONL 文件持续增长后：
Read Entire File
↓
Memory Parse
↓
Pagination性能会逐渐下降。
后续应该改为：
audit/
├── 2026-09-15.jsonl
├── 2026-09-16.jsonl
└── ...或者接入专门的日志系统。
30.3 外部 API 依赖
同步任务依赖外部 API。
当外部 API 不可用时：
Sync
│
▼
External API
│
X
│
▼
Task Failed因此同步系统应考虑：
- 超时
- 重试
- 指数退避
- 任务状态
- 失败告警
- 手动重试
30.4 R2 并发更新
对于低频管理操作问题不大，但高并发更新 JSON 文件存在覆盖风险。
随着数据规模和并发增加，需要引入：
ETag / Optimistic Lock或迁移到数据库。
三十一、架构演进
当前系统可以从：
Admin SPA
│
▼
Cloudflare Worker
│
▼
R2逐步演进为：
Admin SPA
│
▼
┌──────────────┐
│ Admin BFF │
└──────┬───────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Identity Config Audit
│ │ │
▼ ▼ ▼
Database R2 Log Platform
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Monitor Sync Storage进一步可以增加：
1. 更完整的 RBAC
从简单的：
resource + action演进到：
User
↓
Role
↓
Permission
↓
Resource2. 配置版本化
config-v1
config-v2
config-v3支持：
- 配置历史
- Diff
- Rollback
- 发布记录
3. 审计事件化
从：
JSONL演进为：
Audit Event
↓
Queue
↓
Storage / Log System降低管理请求与日志持久化之间的耦合。
4. 任务化同步
从同步 API：
POST /api/sync/task进一步演进为：
Create Job
↓
Queue
↓
Worker
↓
R2
↓
Job Status这样可以更好地处理耗时任务、失败重试和并发控制。
三十二、总结
后台管理 API 的核心并不是简单地把多个接口放进一个 Worker，而是建立一个清晰的管理控制面（Control Plane）。
整体可以抽象为：
Admin SPA
│
▼
┌───────────────┐
│ Admin BFF │
├───────────────┤
│ Authentication│
│ Authorization │
│ API Routing │
│ Encryption │
│ Audit │
└───────┬───────┘
│
┌─────────────┼──────────────┐
▼ ▼ ▼
R2 External APIs Runtime Workers
│
├── Config
├── Cache
├── Audit
├── Static
└── Metrics通过 Cloudflare Workers，可以把管理端所需要的：
认证
权限
配置
同步
存储
审计
上传
监控统一收敛到 Edge BFF 中。
而 R2 则承担轻量级对象数据存储和配置持久化。
这种架构的关键并不是“使用了 Cloudflare Workers”，而是通过统一控制面 + 明确权限边界 + 数据存储分层 + 运行时配置 + 可追溯审计，将一个分散的管理系统组织成一个相对独立、可演进的基础设施服务。
对于低频、管理型、边缘化的后台 API，这是一个具有较高性价比的架构组合。
附：与前端数据链路的关系
如果系统同时存在前端埋点 SDK、BI 数据服务和性能监控服务，可以形成完整的数据闭环：
┌──────────────┐
│ Browser │
└──────┬───────┘
│
│ Events
▼
┌──────────────┐
│ Analytics │
│ SDK │
└──────┬───────┘
│
▼
┌──────────────┐
│ BI Collection│
│ Service │
└──────┬───────┘
│
├─────────────────┐
▼ ▼
Raw Data Monitor
│
▼
R2
│
▼
Admin BFF
│
▼
Admin SPA最终形成：
数据采集 → 数据汇总 → 指标计算 → 数据存储 → 管理查询
的完整链路。
而 Admin BFF 位于整个系统的控制面，负责将配置、数据、权限和运维能力统一提供给管理端。
前端埋点 SDK 设计与实现：从事件采集到可靠上报
Pulsar 是浏览器埋点 SDK，业务通过`track()`上报事件。自动采集设备、会话、环境信息，内存队列批量上报，依托 sendBeacon/fetch‑keepalive 防页面关闭丢数，支持重试，AES‑GCM 加密 + HMAC 签名，兼容 SSR，可扩展持久化队列。
Monorepo 共享包维护体系：从包边界到版本发布的工程化实践
构建 Monorepo 共享包完整维护体系，划分五类包，要求依赖为有向无环图。统一包结构与 API 最小暴露原则，介绍 Fixed/Independent 版本模式，基于 Changesets 做版本管理，搭配全套工具链，设置 CI 门禁，规范包从创建到归档的全生命周期。