Node 版本更高，Bun semver.satisfies 为什么仍返回 false

CI 已经安装了编号更高的 Node，版本检查仍提示“不满足最低版本”。若实际版本是 v27.0.0-alpha.0.0.0，检查使用的是 Bun semver.satisfies(version, '>=26.0.0')，应先看预发布版本的匹配规则。

Bun 1.4.4 有这样的 CI 失败场景，但“排序更大”和“满足版本范围”并不是同一个判断。不能只看到 27 大于 26，就认定范围解析器把数字比错了。

alpha 后缀会影响范围准入

SemVer 的常见范围规则默认不把任意预发布版本纳入稳定版本范围。一个 comparator set 要接受预发布版本，通常需要其中有相同 major、minor、patch 三元组的预发布比较条件。

因此，27.0.0-alpha.0.0.0 在排序上可以高于 26.0.0，却不自动属于默认的 >=26.0.0 范围。Bun 的 semver.order() 用于版本先后比较，semver.satisfies() 用于范围匹配，不能因为两者用途不同而要求返回相同结论。

也不要把范围机械改成 >=26.0.0-0 就认为已允许所有后续 alpha。这个写法的预发布三元组是 26.0.0，并不等价于“任何更高主版本的预发布都允许”。

先确定 CI 应不应该运行预发布版

如果项目支持的是稳定 Node，先检查安装步骤是否使用了会跟随最新发布的宽泛选择器，保留实际解析出的完整版本。可以将 CI 固定到项目已验证的稳定版本线，例如使用 setup-node 的配置片段：

with:
  node-version: '26'

这只是 action 已经存在时的版本输入片段，应与项目的最低支持版本、测试矩阵和锁定策略一致。不要为了绕过一次检查把所有任务都切到同一主版本，尤其不能丢掉原本必须覆盖的旧稳定版本。

如果 alpha 是有意安排的前瞻测试，应把“稳定版兼容性检查”和“允许某些预发布的试验任务”分开定义。需要单纯比较先后时可以评估 semver.order()，但它不能替代包含上限、排除项、多个 comparator set 的一般范围判断。Bun 的该接口也不能直接套用其他 semver 包的 options 参数。

不要删除版本后缀伪装成正式版

把 -alpha... 去掉再匹配，会将一个尚未稳定的运行时伪装成正式版本；它可能有不同接口或兼容性，检查变绿并不代表受到支持。相同道理，直接对 process.version 做字符串大小比较，也不是语义版本判断。

调整后分别检查低于最低要求的稳定版、满足要求的稳定版，以及明确允许或拒绝的预发布版。日志保留原始完整版本和使用的准入策略，确认本地与 CI 采用同一规则。

CI 采用稳定版本还是允许预发布，应由项目支持策略明确决定。更新 Bun 本身不能代替这项准入选择。