环评表列出后如何最终选择：按优先级而非数量或加权

完成[[360度环评法：评估质量属性时不追求过度预留]]之后，会得到一张列出各方案在不同质量属性维度上优劣的环评表，但这张表本身并不会直接告诉你选哪个——因为几乎不会出现某个方案在所有维度上都最优的情况（开源方案工作量小但可运维性和可扩展性差，自研工作量大但可运维可维护性好，C语言性能高但团队技术积累少，Java技术积累多但性能不如C语言……），这时候容易掉进两种看似合理实则有问题的选择方法。第一种是”数量对比法”：单纯数哪个方案占优的维度更多就选哪个（比如5个维度里A方案占优3个、B方案占优2个，就选A）——这个方法的根本问题是把所有质量属性的重要性视为等同，忽略了优先级差异（对BAT这类公司，成本几乎不是问题，可用性和可扩展性远比成本重要；但对创业公司，成本可能才是关键），而且遇到两个方案优点数量打平时会彻底失效，若为了打破平局强行再加一个不重要的维度进去对比，这个临时凑数的维度反而成了决定胜负的关键，本质上还是没解决”优先级”这个根本问题。第二种是”加权法”：给每个质量属性打权重分（比如性能高中低对应10/5/3分，成本高中低对应5/3/1分），累加各方案的加权总分选最高的——问题在于权重分本身缺乏客观标准（为什么性能是10/5/3而不是5/3/1或100/80/60），容易沦为设计师为了让心仪方案胜出而反向调整权重的”数字游戏”。正确的做法是”按优先级选择”：架构师综合当前业务发展阶段、团队规模与技能、未来业务预测等因素，把质量属性按优先级排出先后顺序，先看谁能满足第一优先级，都满足再看第二优先级，依此类推——这个方法之所以在实践中很少卡在”多个方案完全打平”的困境，是因为在设计备选方案阶段就已经要求方案之间的差异必须足够明显，差异明显的方案天然不太可能在每个维度上都表现得一模一样。

结构图：

flowchart TB
  A["环评表列出后如何最终选择"]
  A --> B["❌数量对比法：数占优维度个数<br/>缺陷：质量属性重要性视为等同<br/>易打平，凑数维度反成关键"]
  A --> C["❌加权法：给质量属性打分累加<br/>缺陷：权重分无客观标准<br/>易沦为为选定方案倒推分数的数字游戏"]
  A --> D["✔按优先级选择<br/>结合业务阶段/团队规模技能/业务预测<br/>排出质量属性优先级顺序"]
  D --> D1["先看是否满足第1优先级<br/>都满足→看第2优先级……依次类推"]
  D1 --> D2["因备选方案本身差异明显<br/>实践中极少出现完全打平的情况"]