四种常见的方案挑选思路及其共同缺陷

备选方案设计完成后，挑选哪个方案往往比设计备选方案本身更棘手，原因在于：每个方案都是可行的（不可行的方案本就不该进入候选名单）；没有哪个方案是完美的（A方案有性能短板、B方案有成本短板、C方案有新技术不成熟的风险）；评价标准本身主观性很强（”复杂”这类词很难量化，不同设计师对同一个方案的判断经常直接冲突）。正因如此，实践中常见四种朴素的挑选思路。”最简派”直接挑看起来最简单的方案（如全文搜索用MySQL而非Elasticsearch，图省去索引设计和分布式的麻烦）；”最牛派”正相反，倾向挑技术上最强大、最先进的方案（如缓存选功能更全的Redis而非更简单的Memcache，仅因为”看起来更好”）；”最熟派”基于个人过往经验挑自己最擅长的技术（如C++背景的开发者做运维系统时继续用C++，即使Python/Ruby可能更合适）；”领导派”则是把决策权直接交给领导，方案选对了是领导英明，选错了也是领导背锅，设计师本人不承担判断责任。这四种思路本身没有绝对的对错——有时候确实该选最简单的方案，有时候确实该选最优秀的方案，有时候确实该选团队最熟悉的技术，甚至有时候真的适合领导拍板；它们共同的缺陷是缺少一套系统的判断标准来回答”这次到底该用哪一种思路”，全凭直觉或个人偏好决定，容易在评审时演变成各说各话的争论。

结构图：

flowchart TB
  A["挑选备选方案的四种常见朴素思路"]
  A --> B["最简派：挑最简单的方案<br/>如全文搜索选MySQL而非Elasticsearch"]
  A --> C["最牛派：挑技术最强大的方案<br/>如缓存选功能更全的Redis而非Memcache"]
  A --> D["最熟派：挑自己最熟悉的技术<br/>如C++背景硬用C++做运维系统"]
  A --> E["领导派：交给领导拍板<br/>选对是领导英明，选错领导背锅"]
  B --> F["共同缺陷：都不是绝对错误<br/>但缺少系统标准判断'这次该用哪种思路'"]
  C --> F
  D --> F
  E --> F