01
先区分检查模式
规范化只检查写法，排序按版本优先级排列，匹配则保留输入顺序并评估约束。相同大小的版本在排序后仍保持原次序，非法行移到末尾，原物理行号不会被重新编号。
开发者工具
PEP 440 版本测试看清 Python 版本的顺序与匹配规则
每行输入一个版本，选择规范化、排序或约束匹配，查看逐行报告。
PEP 440 版本测试
版本列表（每行一个）
检查报告
输入内容或载入示例以开始。
输入仅在当前浏览器中处理，不会发送到服务器。
选项
逗号表示 AND；空约束没有版本边界。支持 ~= == != <= >= < > ===，.* 仅可用于 == 或 != 的发布段前缀。
上限：1,000 个非空行；单行 256、约束 2,048、列表 100,000 个 UTF-16 单元。空行跳过，原输入不改写。
正在检查当前候选…
PEP 440 版本测试适合排查“版本看起来更新，为什么仍不满足依赖条件”。合法性、版本大小和候选资格是三个不同的问题，不能只看字符串中的数字，也不能把 npm 的匹配结果直接套用过来。
Python 版本比较允许把 1.0 与 1.0.0 视为等值，却仍会保留规范输出中的段数。准备修改依赖范围前，可以先用这份列表验证 epoch、dev、post 和本地标签究竟影响了哪一步。
为什么使用 PEP 440 版本测试
把原始写法与规范结果放在一起
PEP 440 版本测试会把 v01.1 规范化为 1.1，同时保留原文。展开单行即可看到各个版本段，快速找出大小写、数字前导零或分隔符变化，不必覆盖原输入再回头寻找差异。
解释预发布为何被排除
自动策略先检查整个候选集合。只要存在符合全部条件的非预发布版本，就优先保留这类候选；没有时才回退到符合条件的预发布。增加一条正式版，可能改变其他行的匹配结论。
读懂报告前的三个细节
02
用整份候选列表验证自动策略
删除一个符合条件的正式版，再观察预发布是否回退进入结果。选择“包含”也不会改变大小关系：1.0rc1 仍小于 1.0，因此不能通过 >=1.0。
03
检查结果是否仍是当前版本
自动运行等待 350 毫秒；关闭后可用按钮或 Ctrl/Cmd+Enter。输入或参数一变，旧报告立即禁止导出。示例和清空先给替换预览，应用后可以一次撤销，恢复输入与报告。
从版本写法到候选资格
保留证据的版本规范化
识别 v 前缀、前导零、alpha/beta/preview 等别名以及本地标签分隔符。规范结果不会随意补成三段版本号；1.0.0 仍保留三段，比较时才按规则处理末尾零。
逐段排序，不用字符串猜大小
先比较 epoch，再比较发布数字段，随后处理开发版、预发布、正式版和后发布。本地标签中的纯数字段按整数比较，大于 JavaScript 安全整数范围的数字也不会被舍入。
将多个版本说明符合并判断
支持 ~=、==、!=、<=、>=、<、>、===，逗号表示全部条件同时成立。==1.4.* 和 !=1.4.* 支持发布段前缀，空白行跳过但候选的原行号与重复值会保留。
错误行也进入完整报告
非法版本只影响所在行；约束语法错误会阻止本轮计算，避免被误读为全部不匹配。界面每次增加展示 50 条，JSON 导出始终包含全部已处理结果、原值与稳定错误代码。
输入范围与判断边界
- 只接收版本和版本条件
- 不解析包名、extras、环境标记、requirements 文件、直接 URL 或锁文件，也不读取模块、递增版本或改写项目。这里只判断已提供的候选，不访问 PyPI、不安装依赖，命中不代表接口兼容。
- 不接收其他生态的范围简写
- ^1.2、裸 ~1.2、OR 和连字符范围会报错；兼容发布应写 ~=1.2。空约束没有数值边界，但仍受预发布策略影响。多个逗号之间的空条件会被忽略，不代表逻辑或。
- 本地标签按运算符区别处理
- 本地标签会参与版本排序。公开版本的 == 和 != 条件忽略候选本地标签；条件明确写了本地标签时则比较它。>=1.0+linux 和 ~=1.0+linux 不合法，不能当作私有范围语法使用。
- 任意相等不接纳旧式非法候选
- === 按规范化后的候选写法比较，不使用末尾补零的等值规则。但每个候选仍须是合法版本；即使条件写成 ===legacy，候选 legacy 仍报非法。本页不模拟安装器的旧格式兼容。
- 自动回退只依据当前列表
- dev 也属于预发布。自动模式下，明确指定预发布的正向条件可以接纳它；否则看是否存在满足全部条件的非预发布版本，再决定是否回退。本工具不知道系统中已安装了什么。
- 有明确上限，不静默截断
- 最多 1,000 个非空行，单行 256、约束 2,048、输入列表总计 100,000 个 UTF-16 单元。它们是工具预算，不是规范限制。规范化和排序都只生成报告，不修改原文；空行跳过，重复行保留。
PEP 440 版本测试常见问题
Python 依赖条件中的 ~= 是什么意思？
它把下界和发布段前缀组合起来。~=1.4 相当于从 1.4 开始且限定在 1.* 内，~=1.4.0 则限定在 1.4.* 内。~=1 只有一个数字段，不是合法条件；是否接纳预发布还要单独判断。
为什么预发布单独测试能匹配，放进列表却不能？
自动过滤会在没有合格非预发布候选时回退。加入满足条件的正式版或后发布版本后，整个集合的选择依据变了。“包含”可查看所有满足数值条件的候选；“排除”则始终拒绝预发布。
公开版本和本地版本如何排序？
公开部分相同时，本地版本排在公开版本之后，例如 1.0 < 1.0+abc。本地纯数字段排在文字段之后；规范化后等值的候选保留输入顺序。这与 SemVer 构建元数据不影响大小的规则不同。
版本约束里可以写本地标签吗？
== 和 != 可以，例如 ==1.0+linux.1。>=1.0+linux.1 或 ~=1.0+linux.1 会被拒绝。若只写 ==1.0，则没有要求具体本地构建，因此 1.0+linux.1 也可能满足条件。
在 Python 中应该怎样比较版本号？
可使用 packaging.version.Version 处理符合规范的版本。本页浏览器引擎已用 packaging 26.0 交叉核对。直接比较字符串会把 1.10 与 1.9 排错；其他生态的解析器也未必识别 epoch 和 post。
预发布或后发布后面可以接 .* 吗？
不可以。==1.0.* 是发布段前缀，而 ==1.0rc1.* 与 ==1.0.post1.* 都非法。需要限制这些后缀时应使用精确相等或普通上下界；前缀条件本身也不会绕过预发布策略。
版本结果不符合预期？