weight=0仅降低客户端负载均衡选中概率，不剔除节点或断连，需配合缩短拉取间隔、强制刷新和禁用notify才能实现无损调试，否则应改用setdisable。
weight=0 是一种轻量、可逆的节点临时下线手段，适用于灰度验证、链路调试或小范围故障隔离场景，但必须清楚它的作用边界和配套操作，否则容易出现“看似下线、实则仍被调用”的问题。
weight=0 的真实行为机制
它仅影响客户端本地负载均衡器的选择概率，不触发服务列表变更通知。节点仍保留在客户端缓存中，只是在随机/加权轮询等策略中被选中的概率降为零。这意味着：
- 客户端不会主动剔除该节点，也不会刷新其连接池
- 已建立的长连接（如 RPC 连接）仍可能复用，导致请求继续发往该节点
- 若客户端缓存未更新，且负载策略存在偏差（如最小活跃数），仍有极小概率被选中
实现无损调试的关键操作组合
单设 weight=0 不足以保障无损，需配合以下三项动作：
-
同步缩短客户端拉取间隔：在客户端 Communicator 配置中显式设置
updateInterval=5000（单位毫秒），将默认 30s 拉取周期压缩至 5s 级，加快缓存收敛 -
手动触发一次强制刷新：调用
Communicator.refreshAll()或发送 SIGUSR2 信号（视部署方式而定），避免等待下一轮定时拉取 -
确认服务端已禁用 notify 推送干扰：确保 ServerConfig.xml 中对应
<service></service>节点未开启enableNotify="true"，防止 notify 主动推送全量列表覆盖 weight=0 状态
调试期间如何验证是否真正隔离
不能只看注册中心界面显示 weight=0，要从客户端侧验证：
- 检查客户端日志：搜索
choose endpoint或selected from关键字，确认目标节点未出现在候选列表中 - 抓包验证：在客户端机器上对目标服务端口执行
tcpdump -i any port <svc_port></svc_port>，确认无新建连接或请求数据帧 - 观察指标：监控该节点的入向 QPS、错误率、连接数，应快速归零并维持平稳
何时该停用 weight=0，切回 setDisable
当出现以下任一情况，说明 weight=0 已不适用，应立即改用 setDisable：
- 客户端日志持续出现
ConnectException或超时，表明旧连接未优雅关闭仍在重试 - 多个客户端拉取间隔不一致，导致部分实例仍路由到该节点
- 调试时间超过 1 分钟，且需确保 100% 隔离——此时 setDisable 的秒级全量通知更可靠
