Twine 上传失败又报 HTTPStatus ValueError，保留非标准状态的原始错误

Twine 6.2.0 上传时先出现 499 Client Error，随后又报 ValueError: 499 is not a valid HTTPStatus，要区分原始 HTTP 失败与错误处理阶段的二次异常。后者会让日志看起来像客户端崩溃，却没有说明上游为什么返回 499。

Twine 的命令行入口捕获 requests.HTTPError 后，用标准库 HTTPStatus 枚举查询状态短语。499 不在该枚举中，查询再次抛出 ValueError。请求库已经保留了响应，问题出在错误展示时强行要求状态码必须有标准枚举项。

Twine 7.0.0 包含处理：枚举不认识的代码使用 Unknown Status，同时保留实际状态数字、响应地址及原因。更新工具环境后，上传仍应以失败状态结束；日志能正确显示原错误，并不表示远端已经接收成功。

python -m pip install "twine==7.0.0"
python -m twine --version

可以用本地模拟响应检查命令行入口，不需要向仓库重复上传，也不需要填入 token：

from unittest.mock import patch
import requests
from twine import __main__ as twine_main

response = requests.Response()
response.status_code = 499
response.url = "https://example.invalid/upload"
response.reason = "simulated upstream failure"
error = requests.HTTPError(response=response)
with patch("twine.cli.dispatch", side_effect=error):
    failed = twine_main.main()
assert failed is True

执行时应看到带 499 Unknown Status 的错误信息，并确认没有枚举查询的 ValueError。再用标准状态码做对照，检查标准短语仍能展示。这只验证本地错误处理，不验证认证、上传限额或网络链路。

排查真实上传失败时，保留原始响应状态、时间及服务端请求标识，结合仓库或代理的日志确认原因。非标准状态可能由中间服务产生，但仅凭数字不能断言一定是某个代理超时，也不能把 499 直接改成 200 来继续流程。

再次上传前，先核对远端是否已有对应文件以及项目的发布规则。一次失败的连接不等于所有文件都没有写入；修复错误展示也不会撤销已上传的产物。自动化流程应继续依据命令退出状态与仓库结果处理，不能因为日志更清楚就把失败归为成功。