uv 反复重装同一 wheel，检查 sig 签名被写成星号

同一份requirements反复执行 uv pip install，总是把同一个wheel先卸载再安装。包版本没有变化，但直接下载URL带 sig=，安装后的direct_url.json里却是 sig=****，要检查来源记录是否与真实需求失配。

uv0.12.8至0.12.18有这条具体记录：原本用于展示的签名脱敏进入安装元数据，下一次比较来源时，真实URL和星号URL不相等。仅看到控制台里的星号并不足以确定触发；正常日志本来就应该遮盖签名。

比较同一环境里的需求与来源记录

确认调用的uv版本、目标虚拟环境，以及输入确实是同一份直接URL需求。只在本地受控位置读取该包dist-info中的direct_url.json，核对其url字段是否已经被星号替换；不要把含有效签名的原URL、requirements或元数据贴进公共日志。

以下命令只展示已有项目的计划检查入口，文件名需要替换为实际私有依赖文件：

uv pip install --dry-run -r requirements-private.txt

dry-run不应被当作离线操作，它仍可能访问依赖来源。如果计划反复出现同一包的卸载和安装，先核对来源，而不是加更多重试或认为缓存一定损坏。

URL签名过期、调用方每次产生新的下载URL，以及包版本约束变化，也会带来重新获取或重装需求。这些情况与“同一个真实URL被保存成星号”的路径不同，应分别处理。

更新安装器后，重建正确的来源元数据

正式uv0.13.5把URL的展示脱敏与元数据序列化分开：direct_url使用的序列化策略去除URL用户名和密码，但保留sig查询值；来源比较仍基于实际解析后的URL。这是可以核对的正式实现边界，不代表任意更高版本都无需验证。

可以在项目支持范围内采用包含正确来源记录的安装器，再按原来批准的依赖来源完成一次受控安装，使旧的错误元数据被正常替换。不要直接把星号字符串改成猜测的签名，也不要通过编辑dist-info伪造一个“已经满足”的安装状态。

签名查询值可能作为获取私有工件的凭据存在于本地元数据中，应限制相关环境、依赖文件和备份的访问权限。日志脱敏仍应保留，不能为排查重装关闭整套凭据保护。

暂时不能更新时，如果业务发布渠道允许，可评估使用稳定、受控且有完整性校验的工件来源或项目管理的本地wheel。来源变更须同时核对版本、平台、哈希和授权，不能为消除sig就去掉真实下载所必需的认证参数。

处理后使用同一份有效需求再次查看计划，确认没有无故重装，再验证包的实际导入和应用功能。签名已经过期时，应按原授权渠道重新取得工件，不应把一次重装消失当成凭据永不过期的保证。