Vite 发布策略详解：语义化版本、版本支持范围、预发布与弃用规则

本文基于 Vite 仓库的官方发布说明（docs/releases.md），系统梳理 Vite 的版本发布策略：Patch/Minor/Major 的发布节奏、受支持版本范围的自动推导规则、预发布版本的使用约束、弃用（Deprecation）与实验性（Experimental）功能的边界，并结合仓库中的版本支持组件与发布脚本源码，说明这些策略在工程上是如何落地执行的。读完本文，你将能够准确判断任意一个 Vite 版本是否仍在支持期内、正确制定升级与版本锁定策略，并理解 Vite 从提交到 npm 发布的完整自动化链路。

版本基础：语义化版本与完整变更日志

Vite 的发布遵循**语义化版本（Semantic Versioning, SemVer）**规范，即 主版本.次版本.修订号（major.minor.patch）三段式版本号。最新稳定版本可以直接在 Vite 的 npm 包页面上查看。

所有历史发布的完整变更日志（changelog）维护在仓库内：packages/vite/CHANGELOG.md。该文件由发布工具链自动生成，按版本倒序排列，每个版本区块包含 BREAKING CHANGES、Features、Bug Fixes、Performance Improvements 等分类条目，并附带各条目对应的 PR 与提交链接。以当前仓库中的版本为例，packages/vite/package.json 中声明的版本为 8.2.2，其对应条目即位于 CHANGELOG 顶部。

发布周期：无固定节奏，但各级别发布有明确规律

Vite 没有固定的发布周期，各级别版本的发布节奏如下：

• Patch（修订号）发布：按需发布，通常是每周一次，用于修复已有版本中的缺陷；
• Minor（次版本）发布：必然包含新功能，按需发布（通常每两个月一次）。每个 Minor 版本都会经历一个 beta 预发布阶段；
• Major（主版本）发布：通常与 Node.js 的 EOL（停止维护）时间表对齐，并会提前公告。Major 版本发布前会与生态社区进行长期讨论，并经历 alpha 和 beta 两个预发布阶段（通常每年一次）。

这一节奏意味着：如果你依赖 Patch 级的安全或稳定性修复，每周都有机会获得更新；而涉及破坏性变更的 Major 版本，则会以 Node.js LTS 生命周期为锚点，给生态留出迁移时间。

受支持版本：三条支持边界与自动推导规则

官方文档给出的支持范围可以概括为四条规则：

1. Current Minor（当前 Minor）：获得常规修复（regular patches）；
2. Previous Major（上一主版本，仅其最新 Minor） 与 Previous Minor（上一 Minor）：获得重要修复与安全补丁；
3. Second-to-last Major（上上主版本，仅其最新 Minor） 与 Second-to-last Minor（上上 Minor）：仅获得安全补丁；
4. 早于以上范围的版本不再受支持，应当升级。

这段文字中的支持范围并非人工维护，而是由文档站点组件 自动计算 的。查看 docs/.vitepress/theme/components/SupportedVersions.vue 的源码可以看到核心逻辑：

// SupportedVersions.vue 中的支持信息推导
return {
  regularPatches: f([`${major}.${minor}`]),                       // 当前 Minor
  importantFixes: f([`${major - 1}`, `${major}.${minor - 1}`]),   // 上一 Major + 上一 Minor
  securityPatches: f([`${major - 2}`, `${major}.${minor - 2}`]),  // 上上 Major + 上上 Minor
}

其中 f 函数会查一张“上一主版本最终 Minor”映射表，确保“仅其最新 Minor”这一约束得到落实：

const previousMajorLatestMinors: Record<string, string> = {
  '2': '2.9',
  '3': '3.2',
  '4': '4.5',
  '5': '5.4',
  '6': '6.4',
  '7': '7.3',
}

以当前仓库的 Vite 8.2.2 为例，按上述规则推导出的支持范围是：

支持级别	覆盖版本	说明
常规修复	8.2	当前 Minor，所有 8.2.x 补丁发布
重要修复 + 安全补丁	7.3（上一 Major 的最终 Minor）、8.1	只回移植重要修复与安全补丁
仅安全补丁	6.4（上上 Major 的最终 Minor）、8.0	只回移植安全补丁
不再支持	8.0 之前的 8.x、7.3 之前的 7.x、6.4 之前的所有版本	建议升级

该组件还在文档站点上提供了一个交互输入框，让用户输入自己正在使用的版本号（如 7.1.0），通过同主版本 + 次版本不小于受支持版本下限的比较逻辑（parsedVersion.major === compared.major && parsedVersion.minor >= compared.minor）即时判定“supported / not supported”。此外源码中还有两个边界约定值得注意：

• isValidViteVersion 显式排除了 0.x（不应被提及）和 1.x（从未发布）版本；
• 判定逻辑中“未来的 Major 版本”一律视为受支持，避免新版本发布瞬间出现误判。

组件渲染的版本列表由 docs/.vitepress/theme/components/VersionsList.vue 以 vite@x.y 代码样式输出，保证读者看到的始终是与当前文档构建所用 Vite 版本一致的实时结果。

官方建议是定期升级 Vite。每次升级到新的 Major 时，应查阅 迁移指南。Vite 团队会与生态中的主要项目密切合作保障新版本质量：新 Vite 版本发布前会先通过 vite-ecosystem-ci 项目（生态集成 CI 项目，独立于本仓库维护）进行生态兼容性测试，大多数基于 Vite 的项目应能在新版本发布后快速提供支持或完成迁移。

语义化版本的两个边缘情况

TypeScript 定义文件可能在 Minor 间发生不兼容变更

这是 SemVer 在 Vite 上的一个特殊例外：TypeScript 类型定义可能在 Minor 版本之间出现不兼容变更。原因有三：

• TypeScript 自身有时会在 Minor 版本间发布不兼容变更，Vite 需要调整类型以适配更新的 TypeScript；
• 偶尔 Vite 需要使用仅在更新版本 TypeScript 中才存在的特性，从而提高 TypeScript 的最低要求版本；
• 官方给出的应对建议：如果你使用 TypeScript，可以使用锁定当前 Minor 的 semver 范围（例如精确到次版本），并在新 Minor 发布后手动升级验证。

非 LTS 的 Node.js 版本

奇数版本的非 LTS Node.js 不纳入 Vite 的 CI 测试范围，但在其 EOL 之前理论上仍应可以工作。也就是说，官方承诺的测试矩阵只覆盖 LTS 版本。从仓库 packages/vite/package.json 的 engines 字段可以确认当前主版本对运行时的要求：

"engines": {
  "node": "^20.19.0 || >=22.12.0"
}

即当前 Vite 8.x 要求 Node.js 20.19.0 以上的 20.x 分支或 22.12.0 及以上版本——这也印证了 Major 版本与 Node.js 生命周期对齐的策略。

预发布版本（Pre Releases）：beta 与 alpha 的定位

• Minor 版本：通常经历数量不固定的若干次 beta 预发布；
• Major 版本：经历 alpha 阶段 和 beta 阶段。

预发布的目标是让早期采纳者和生态维护者进行集成与稳定性测试并提供反馈。官方对此有三条明确的使用约束：

1. 不要在生产环境使用预发布版本；
2. 所有预发布版本均视为不稳定，相邻预发布之间可能引入破坏性变更；
3. 使用预发布版本时必须锁定精确版本（pin to exact versions），不要使用范围匹配。

预发布在发布工程上的落地可以从仓库的变更日志脚本看到佐证。scripts/mergeChangelog.ts 专门负责在主版本正式发布时，把该主版本下所有预发布（如 8.0.0-beta.1、8.0.0-rc.0）的 changelog 条目去重、按分类（BREAKING CHANGES / Features / Bug Fixes / Performance Improvements / Documentation / Miscellaneous Chores / Code Refactoring / Tests）重排后合并为单一稳定版区块，并追加一个指向各预发布 tag 的 “Beta Changelogs” 索引小节。这解释了为什么 packages/vite/CHANGELOG.md 中一个 Major 稳定版能看到汇总后的完整变更记录，同时仍可追溯每个 beta/rc 的独立条目。

弃用（Deprecation）：进入弃用状态后一个 Major 的生存期

Vite 会在 Minor 版本中周期性地弃用那些已被更好方案取代的功能。其生命周期规则是：

• 被弃用的功能继续可用，但会伴随类型层面（非继承的类型标记）或运行时警告（logged warning）；
• 该功能将在进入弃用状态之后的下一个 Major 版本中被移除；
• 每个 Major 版本的 迁移指南 会列出这些被移除项，并给出对应的升级路径。

这条规则实际上定义了一个“弃用观察窗口”：某个功能在 x.y 被标记弃用，那么在 x.y+1 到 x+1.0 之间的所有版本中它都仍然工作，用户有至少一个 Major 的周期完成迁移。

实验性功能（Experimental Features）：生产可用但设计不稳定

部分功能会在稳定版本中发布，但被明确标记为实验性（experimental）。其设计意图与使用约束是：

• 目的：通过让用户在生产环境中试用，收集真实世界的经验，最终影响功能的定型设计；
• 实验性功能本身被视为不稳定，应当只在受控的方式下使用；
• 这些功能可能在 Minor 版本之间发生变化，因此依赖它们的项目必须锁定 Vite 版本；
• 每个实验性功能都会对应一个 GitHub 上的 Discussion（实验性功能反馈区），作为生态反馈的集中入口。

从提交到 npm：发布流程在仓库中的实现

上述发布策略由一套自动化脚本支撑，均位于仓库 scripts/ 目录，并基于统一的发布工具库 @vitejs/release-scripts：

1. 发布识别：scripts/detect-release.ts 接收一个发布提交的 subject，调用 detectReleaseCommit 判定该提交是否为某个包（vite、create-vite、plugin-legacy 三者的发布清单定义在 scripts/releaseUtils.ts）的发布动作，并输出包名、tag 与目标版本号；
2. 发布准备：scripts/prepare-release.ts 调用 prepareRelease 提升包版本、按包生成 tag（vite 包用 v 前缀，其余包用 pkg@ 前缀）、生成变更日志条目，然后组装出包含 changelog 的发布 PR 正文——也就是说，每个版本对应一个自动生成、包含完整 changelog 的发布 PR；
3. 变更日志提取：scripts/extract-changelog.ts 可以从 CHANGELOG.md 中按版本号抽出对应条目，供发布说明复用；
4. npm 发布：scripts/publishCI.ts 调用 publish（指定包管理器为 pnpm）完成向 npm 的发布；
5. 主版本变更日志合并：scripts/mergeChangelog.ts 将预发布条目合并进稳定版区块（上一节已述）。

scripts/releaseUtils.ts 中还有一处体现版本策略的细节：updateTemplateVersions 会在 create-vite 发布时，把 packages/create-vite/ 下所有 template-* 模板的 devDependencies.vite 统一改写为 ^ + 当前 Vite 稳定版本号——且当版本号匹配 /beta|alpha|rc/ 时会直接跳过，保证官方模板始终指向稳定版，与“预发布不得用于生产”的原则保持一致。

总结：版本治理的核心规则一览

规则	内容
版本规范	SemVer；完整 changelog 见 packages/vite/CHANGELOG.md
发布节奏	Patch 按需（约每周）；Minor 含新功能、先 beta（约每两个月）；Major 对齐 Node.js EOL、经 alpha + beta（约每年）
支持范围	当前 Minor 获常规修复；上一 Major（最终 Minor）与上一 Minor 获重要修复 + 安全补丁；上上 Major（最终 Minor）与上上 Minor 仅获安全补丁；更早版本停止支持
已知例外	TypeScript 类型定义可能跨 Minor 不兼容，建议按 Minor 锁定并手动升级
运行环境	当前主版本要求 Node.js ^20.19.0 || >=22.12.0（见 packages/vite/package.json）；非 LTS Node.js 不纳入 CI 测试
预发布	生产禁用、视为不稳定、必须锁定精确版本
弃用	Minor 中标记（类型或警告提示），进入弃用状态后的下一个 Major 移除
实验功能	生产受控使用、可能在 Minor 间变化、依赖方必须锁定版本

对使用者的直接含义可以归纳为三条：定期跟进 Patch/Minor 升级以获得安全补丁；跨 Major 升级前必读 迁移指南；对预发布和实验性功能一律锁定精确版本，并避免在生产环境直接依赖。