etcdctl 带 user 的 --cluster 仍报空用户名，检查成员发现传递

使用同一份身份信息，member list 可以成功，endpoint health --cluster 却报空用户名。在 etcd 3.6.9 上遇到这组症状时，应把成员发现与后续端点操作分开看：--cluster 会先查询成员列表，再把发现的端点用于命令。

旧的发现辅助路径有意排除了 Auth 配置，因为此前查询成员列表不要求认证。MemberList 的权限收紧后，这条路径仍没有把命令的认证配置传过去；于是调用者已经提供用户信息，发现请求却按无认证方式发送。正式 etcdctl 3.6.10 补上了这项传递。

这和“没有提供身份时 health 失败”不同，也不应通过关闭集群认证解决。更新的重点是实际使用的 etcdctl 客户端；同时按集群维护要求核对客户端与服务端兼容性，不要求为了绕过权限检查回退服务端。

在已有授权的管理环境中，使用同一身份比较直接端点与发现路径。--user admin 可交互输入密码，命令示例不把密码写进参数；端点和 TLS 参数替换为组织实际配置：

etcdctl version
etcdctl --endpoints=https://已有端点:2379 --user admin member list
etcdctl --endpoints=https://已有端点:2379 --user admin endpoint status
etcdctl --endpoints=https://已有端点:2379 --user admin endpoint status --cluster

TLS 集群继续提供已有 CA、客户端证书和私钥参数，不因示例省略它们就改成明文。先确保 direct member list 确实有权读取，再看 --cluster 是否还报空用户名。如果直接成员列表本身被拒绝，需要处理实际身份或权限，不能把所有认证失败归为客户端漏传。

暂时无法更新客户端时，可对运维系统已知且可信的端点列表逐一操作，避开发现路径。这个列表不会自动跟随成员变化，应由现有集群配置维护；不要从不可信日志或外部输入拼接端点。

升级后重复相同的比较，检查发现到的成员与集群实际配置一致，并确认后续请求的 TLS 和身份要求仍满足。成员发现成功不代表所有端点的网络、证书和业务健康都正常；还要逐项看命令结果。

endpoint health 会检查服务健康，实际执行应遵循集群的运维流程。对身份的要求也保持原样：如果成员列表需要管理员权限，修复不会自动提升普通账号权限。不要为了让脚本通过而给无关账号授予管理员角色。