第3章 核心评估维度概览
3.1 为什么需要多维评估框架
本地持久化技术选型不是单一指标的比拼，而是要在性能、易用性、跨平台、版本迁移、存储容量、安全性六个约束维度下寻找平衡解。每个维度都对应着架构方案上的不同决策边界：
- 性能决定读写吞吐与延迟，影响上层业务是否流畅；
- 易用性决定开发效率和维护成本，直接影响团队上手速度；
- 跨平台决定技术栈能否在多个操作系统或硬件上统一；
- 版本迁移决定数据模型演进时的兼容风险和回退能力；
- 存储容量决定单机可承载数据规模及增长瓶颈；
- 安全性决定数据加密、访问控制和合规底线。
3.2 六维评估框架一览
| 评估维度 | 核心关注点 | 常见竞品指标 | 架构影响范围 |
|---|---|---|---|
| 性能 | 读写延迟、吞吐、并发能力 | QPS, 99%ile 延迟, IOPS | 存储引擎、索引结构、缓存策略 |
| 易用性 | API 简洁度、文档、社区生态 | Demo 上手时间、IDE 支持 | 开发规范、ORM 集成、调试难度 |
| 跨平台 | Windows/Linux/macOS/iOS/Android | 平台覆盖数、原生 vs 绑定 | 构建系统、依赖库、ABI 兼容 |
| 版本迁移 | Schema 演进、向后兼容、回滚 | 迁移工具、冲突率、自动迁移 | 序列化格式、升级策略、测试覆盖 |
| 存储容量 | 单文件上限、数据库膨胀 | 最大文件大小、WAL 机制 | 分库分表、压缩策略、清理策略 |
| 安全性 | 加密、访问控制、防注入 | 加密算法、密钥管理、认证 | 安全模块、权限模型、审计日志 |
架构师视角： 六维评估不是打勾清单，而是决策时的约束优先级排序。例如金融类应用通常将安全性列为最高优先级，而 IoT 端侧则更优先考虑性能与存储容量。
3.3 各维度关键权衡与风险
- 性能 vs 安全性： 加密写入通常带来 10%~30% 的性能损耗，需评估业务敏感度。
- 易用性 vs 版本迁移： 全自动迁移工具降低易用性门槛，但可能隐蔽破坏原有数据模型。
- 跨平台 vs 存储容量： 某些跨平台方案（如 SQLite）单文件上限受限于底层文件系统，大容量场景需要分库。
典型风险： 单纯追求最高性能而忽略版本迁移能力，可能导致线上数据模型升级时出现回滚困难；反之过度强调易用性，使用黑盒迁移方案可能引入隐式 Schema 冲突。建议在技术选型阶段就定义好每个维度的 最低可接受指标。
3.4 落地步骤与验收标准
落地步骤（六步法）：
- 定优先级： 与业务方确认三个最高优先级的评估维度。
- 定阈值： 为每个维度设定可量化的最差可接受值（如 99%ile 延迟 < 50ms）。
- 初筛： 基于产品文档和社区数据淘汰掉不满足阈值的候选技术。
- PoC 验证： 针对剩余候选技术编写基准测试用例，采集各维度的真实数据。
- 打分权衡： 使用加权评分表对比候选方案，重点检查是否存在“一票否决”维度的严重缺陷。
- 架构评审： 输出《评估维度权衡报告》并组织架构评审。
验收标准：
- 每个维度都有明确的可度量的基线值（如性能：并发 1000 读写，延迟 p99 < 30ms）。
- 权衡决策日志记录了每个维度的取舍原因以及对应风险。
- 技术选型报告被至少两位架构师评审通过。