一、前置思考

1.1 为什么技术选型决定项目生死？

选错技术栈的代价:
  → 开发到一半发现天花板 (性能/生态/人)
  → 重构成本 = 数倍原开发成本
  → 团队士气与交付节奏双崩

技术选型不是"哪个最好"
  → 而是"在约束条件下，哪个最适合"
  → 约束: 团队能力 / 时间 / 性能 / 生态 / 维护成本

1.2 选型的本质

选型 = 在"收益"和"代价"之间做权衡

收益: 性能 / 开发效率 / 体验 / 生态
代价: 学习成本 / 维护成本 / 迁移成本 / 风险

没有免费的午餐:
  → 快 = 可能牺牲可控性
  → 强 = 可能牺牲简单性
  → 全 = 可能牺牲性能

二、核心原理

2.1 选型决策框架

五步决策法:
  1. 明确约束: 时间/人力/预算/性能硬指标
  2. 列出候选: 主流方案全列出来
  3. 多维评估: 每个方案打分 (见矩阵)
  4. 验证假设: 关键疑虑做 POC 验证
  5. 定案留退: 选主方案 + 留备选方案

关键原则:
  → 用数据决策，不用喜好决策
  → 无法验证的假设，先 POC
  → 决策可回退: 别选"上船容易下船难"的方案

2.2 四类核心选型维度

UI 方案: ArkUI 原生 / 跨端框架 / 混合
  指标: 性能上限 / 生态 / 团队技能 / 多端需求

存储方案: Preferences / KV / RDB / 分布式 / 混合
  指标: 数据量 / 并发 / 一致性 / 跨设备需求

通信方案: HTTP / WebSocket / 软总线 / 自定义协议
  指标: 实时性 / 可靠性 / 带宽 / 场景复杂度

架构模式: 分层 / MVVM / Clean / DDD / 模块化
  指标: 团队规模 / 业务复杂度 / 长期演进

2.3 评估矩阵打分法

维度权重 × 评分 = 加权得分

示例: UI 方案评估
┌──────────┬────┬──────┬──────┬──────┐
│ 维度(权重)│ArkUI│ 混合 │跨端RN│跨端Fl│
├──────────┼────┼──────┼──────┼──────┤
│性能(0.3) │ 10 │  7   │  6   │  7   │
│生态(0.2) │  9 │  7   │  8   │  7   │
│效率(0.2) │  7 │  8   │  9   │  8   │
│多端(0.15)│  5 │  8   │  9   │  9   │
│人(0.15)  │  8 │  7   │  9   │  6   │
├──────────┼────┼──────┼──────┼──────┤
│加权总分  │ 8.2│ 7.4  │ 7.9  │ 7.4  │
└──────────┴────┴──────┴──────┴──────┘

→ 权重反映项目优先级，评分要基于事实与 POC

2.4 取舍原则

1. 性能敏感选专业: 渲染/计算密集型用最专的方案
2. 存量资产优先: 已有的代码/团队技能是巨大优势
3. 简单优先: 能简单不复杂 (复杂度是负债)
4. 生态看趋势: 选活跃、社区大的方向
5. 可回退原则: 避免"开弓没有回头箭"的决策
6. 20% 原则: 20% 核心场景决定 80% 的选型权重

三、源码/API 深度解析

3.1 存储选型决策树

数据选型决策树:
  是否跨设备同步?
    ├─ 是 → 分布式存储 (KV/RDB 分布式)
    └─ 否 → 数据量多大?
        ├─ 小 (配置/偏好) → Preferences
        ├─ 中 (缓存/计数器) → KV Store
        └─ 大 (结构化业务数据) → RelationalStore
  是否需要复杂查询/事务?
    ├─ 是 → RDB (SQL 能力)
    └─ 否 → KV 更简单高效
  并发写频繁?
    ├─ 是 → 评估 WAL + 批量写
    └─ 否 → 常规即可

3.2 通信方案决策

通信选型决策树:
  是否需要实时推送?
    ├─ 是 → WebSocket / 长连接
    └─ 否 → 请求响应就够 (HTTP)
  是否跨设备?
    ├─ 是 → 软总线 (设备发现/组网)
    └─ 否 → 标准 HTTP
  数据量/带宽?
    ├─ 大 → 压缩/二进制协议
    └─ 小 → JSON 即可
  可靠性要求?
    ├─ 高 → 消息确认 + 重试 + 幂等
    └─ 一般 → 常规超时重试

3.3 POC 验证清单

// 关键假设必须 POC 验证, 不能拍脑袋
// 示例: 验证 LazyForEach 能否支撑 10 万条列表

@Entry
@ComponentV2
struct TechDecisionDemo {
  @Local topic: string = 'UI 方案';
  @Local decision: string = '待评估';
  @Local scores: string[] = [];
  @Local logs: string[] = [];

  private runDecision(): void {
    this.logs = [];
    this.scores = [];
    this.topic = '存储方案选型';
    this.log('🧮 存储选型评估 (项目约束: 100万条IM消息)');
    this.log('候选: Preferences / KV / RDB / 分布式');
    this.log('');
    this.log('数据量: 100万条 → Preferences/KV 淘汰');
    this.log('查询需求: 按会话+时间分页 → 需要 SQL');
    this.log('并发: 多会话同时写 → RDB 事务 + WAL');
    this.log('跨设备: 暂不需要 → 不用分布式 (省复杂度)');
    this.log('');
    this.log('结论: RelationalStore (RDB)');
    this.log('  ✅ 满足查询/并发/数据量');
    this.log('  ✅ 复杂度可控 (无分布式成本)');
    this.log('  ✅ 团队熟悉 SQL');
    this.log('  保留: 未来跨设备需求 → 分布式 RDB 可平滑演进');
    this.decision = 'RelationalStore (RDB)';
  }

  build() {
    Column({ space: 12 }) {
      Text('🧭 技术选型决策演示').fontSize(20).fontWeight(FontWeight.Bold)
      Text('主题: ' + this.topic + ' · 决策: ' + this.decision).fontSize(13).fontColor('#D4A72C')

      Row({ space: 8 }) {
        Button('▶ 模拟选型决策').layoutWeight(1).height(40).fontSize(12)
          .onClick(() => this.runDecision())
        Button('清空').height(40).fontSize(12)
          .onClick(() => this.logs = [])
      }
      .width('100%')

      Scroll() {
        Column() {
          ForEach(this.logs, (l: string) => {
            Text(l).fontSize(11).lineHeight(18).fontColor('#24292F').width('100%')
          }, (l: string, i: number) => l + i)
        }.width('100%')
      }
      .layoutWeight(1).width('100%').scrollBar(BarState.Off)
    }
    .width('100%').height('100%').padding(16)
    .backgroundColor('#F6F8FA')
  }
}

四、企业级实战落地

4.1 常见场景选型速查

场景	推荐方案	关键理由
配置/偏好	Preferences	简单、同步快
高频计数器	KV Store	mmap 高效
结构化业务	RDB	SQL + 事务
跨设备同步	分布式存储	自动同步
实时推送	WebSocket	双向实时
设备互联	软总线	发现+组网
大图列表	LazyForEach	内存可控
核心动画	ArkUI 动画	原生性能

4.2 选型会议模板

技术选型评审会模板:
  1. 业务需求与约束 (背景)
  2. 候选方案清单 (≥3 个)
  3. 评估维度与权重 (达成一致)
  4. 评分表 (数据说话)
  5. POC 结果 (关键假设验证)
  6. 风险与回退方案 (下船方案)
  7. 决策与记录 (留档可追溯)

4.3 决策记录清单

1. 记录约束条件 (为什么当时这么选)
2. 记录被否决的方案及理由 (防止重复讨论)
3. 记录 POC 结论 (数据依据)
4. 记录回退条件 (何时需要重新评估)
5. 定期复审 (技术演进后重新审视)

五、问题排查与性能优化

问题	原因	解决
选了不合适的方案	没验证假设	关键点 POC 先行
评分主观	维度权重不清	权重达成一致 + 数据打分
方案锁死	无回退方案	选可迁移的技术
忽略团队	只比技术	团队技能纳入权重
过度设计	为未来买单	只解决当下 + 近期需求
决策无人负责	会议式决策	明确 Owner + 记录留档

5.1 选型风险控制

1. 双方案并行: 核心模块两个方案做 POC
2. 抽象隔离: 选型变化只影响适配层
3. 渐进切换: 新方案灰度引入, 老方案并行
4. 定期复审: 每季度审视一次技术栈健康度
5. 专家外脑: 重大决策引入外部评审

六、高阶总结与最佳实践

1. 约束先行：先明确时间、人力、性能硬指标，再谈方案。
2. 数据决策：评分矩阵 + POC 验证，杜绝喜好投票。
3. 简单优先：复杂度是负债，能简单绝不过度设计。
4. 可回退：选"上船容易下船也容易"的方案，留后路。
5. 记录留档：决策依据、否决理由、复审周期全部记录。

一句话记住：技术选型 = 约束明确 + 候选齐全 + 权重评分 + POC 验证 + 可回退设计，用数据而非喜好做决策，让每次选型都对得起项目的时间。