Appearance
事件存储
本页整理旧 docs/EVENT_STORE_SYSTEM.md 的核心设计，用来说明 SoulBrowser 为什么需要事件存储，而不是只保留最后结果。
为什么需要事件存储
浏览器自动化系统天然需要保留过程信息，用于：
- 调试和回放
- 审计和追踪
- 时间线展示
- 导出任务证据
所以事件存储不只是日志系统，而是产品运行态的一部分。
双层模型
旧设计里强调热存储和冷存储分层：
- Hot Storage：面向实时写入和短期读取
- Cold Storage：面向持久化和历史查询
这类分层适合处理：
- 高频事件快速流入
- 后续回放和导出
- 大量 observation / overlay / audit 数据
事件模型
一个可用的事件模型通常至少要包含：
- event type
- timestamp
- route / session / task 上下文
- payload
- 附加元数据
这样前端、时间线、导出和排障工具才能共享同一批事实。
与 timeline 的关系
timeline 服务并不是独立生成真相，而是消费 event store。
也就是说：
- event store 是底层事实
- timeline 是面向展示与查询的视图
幂等性和脱敏
旧文档特别强调两件事：
- 幂等性：避免重复写入或重复消费
- 数据脱敏：避免把敏感内容直接沉到底层存储
这两点直接关系到上线后的可靠性和合规性。
对开发的启发
- 不要把截图、状态、审计信息散落在多个完全无关的存储里。
- 新增运行态事件时，要考虑它是否应该进入 event store。
- 如果一个问题无法从 event / timeline 里复盘，通常说明底层事实沉淀不够。