least_conn天然适合异构环境，因其不依赖预设权重，只依据实时活跃连接数动态调度，使高配节点自然承接更多请求；配合max_conns可设不同容量上限，keepalive需合理配置避免账面失真，并须启用健康检查剔除假存活节点。
least_conn 本身不直接支持权重（weight），但它能天然适配异构服务器场景——不是靠预设比例，而是靠实时连接数动态反映真实负载能力。
为什么 least_conn 天然适合异构环境
异构服务器（比如一台 32C64G 高配节点 + 两台 8C16G 普配节点）在轮询或加权轮询下容易失衡：高配节点可能因响应快被快速“填满”，而普配节点还没处理完上一个慢请求，新请求又来了。least_conn 不依赖理论性能，只看“此刻手上还有几个连接没关”，让调度结果自动向实际吞吐能力对齐。
用 max_conns 实现软性容量区分
虽然不能写 weight=3，但可以通过 max_conns 为不同配置的节点设置连接上限，间接体现服务能力差异：
- 高性能节点可设更高上限，例如
server 192.168.1.10:8080 max_conns=2000; - 普通节点设较低上限，例如
server 192.168.1.11:8080 max_conns=800; - 当某节点达到
max_conns，Nginx 会跳过它，即使它的连接数仍是当前最小值（注意：这是硬性规避，不是比较逻辑的一部分）
配合 keepalive 的注意事项
upstream 中启用 keepalive 能复用连接、降低握手开销，但要注意：
- keepalive 空闲连接会计入活跃连接总数，影响 least_conn 判断
- 若高配节点配置了过大的
keepalive 200，而普配节点只配keepalive 50，可能导致“账面连接数”人为失真 - 建议统一设置合理值（如 32 或 64），或根据后端连接池容量反推
健康检查必须同步开启
least_conn 只在健康节点中选最小连接数。如果某台普配节点因 GC 卡顿导致响应延迟升高但 TCP 连接未断，它仍会被计入候选——此时需搭配主动健康检查（check 或 max_fails/fail_timeout）及时剔除异常节点，避免调度到“假存活”实例。
