详细方案设计阶段的技术选型是轻量级的：按适用场景匹配即可

详细方案设计的本质是把已经选定的备选方案里涉及的关键技术细节逐一确定下来（比如确定用Elasticsearch做全文搜索后，还要定索引是按业务拆分还是用一个大索引、副本数是2个还是4个；确定用MySQL分库分表后，还要定分哪些表、按什么维度分、分完后联合查询怎么处理）。这个阶段容易和备选方案阶段混淆，因为两者看起来都是在”选技术方案”（比如Nginx负载均衡策略有轮询、加权轮询、ip_hash、fair、url_hash五种可选），但两者的决策重量级完全不同：备选方案阶段的选择要走[[环评表列出后如何最终选择：按优先级而非数量或加权]]那套完整评估流程，而详细方案设计阶段的技术点选择是很轻量级的，只需要弄清每种技术的适用场景、按业务实际需求直接匹配即可，不需要再走一遍环评。以Nginx负载均衡为例：轮询（默认策略）按时间顺序把请求依次分配到各后端服务器，后端故障时能自动剔除，适合服务器性能相近的常规场景；加权轮询在轮询基础上按权重分配请求量，适合新老服务器混用、性能不均衡的场景；ip_hash按访问IP的哈希结果把同一个访客固定分配到同一台后端服务器，用来解决session问题，典型场景是购物车类应用；fair按后端服务器的实际响应时间分配请求、响应快的优先分配，能更好地平衡各服务器压力，还能防止性能不足的服务器因持续接收同样多请求而引发雪崩；url_hash按访问URL的哈希结果做定向分配，适合后端服务器能够缓存URL响应结果的场景。这几种策略的适用边界区分很明确，只要业务需求清楚（比如电商场景和session强相关，用ip_hash比较合适），挑选起来不构成真正的决策难题。

结构图：

flowchart TB
  A["Nginx负载均衡策略：按适用场景直接匹配"]
  A --> B["轮询(默认)<br/>按时间顺序分配，故障自动剔除<br/>→ 后端性能相近的常规场景"]
  A --> C["加权轮询<br/>按权重分配请求量<br/>→ 新老服务器混用、性能不均"]
  A --> D["ip_hash<br/>同一访客固定同一后端<br/>→ 解决session问题，如购物车"]
  A --> E["fair<br/>按响应时间分配，响应快优先<br/>→ 平衡压力，防止雪崩效应"]
  A --> F["url_hash<br/>同一URL定向同一后端<br/>→ 后端可缓存URL响应结果"]