标准答案
- patch 表示补丁版本，通常用于 bug fix、安全修复和不改变公开 API 的兼容修复。
- minor 表示次版本，通常用于向后兼容的新能力，也可能包含较小行为调整。
- major 表示主版本，通常允许破坏性变更，例如 API 删除、默认行为变化、运行环境要求变化。
- SemVer 是风险信号，不是安全保证；库是否严格遵守、生态依赖是否兼容、锁文件如何变化都要检查。
- 应用依赖升级要看影响面、回滚方式和验证结果，不能只看版本号位数。
题目解析
SemVer 的价值是让使用方先按版本号判断升级预期。比如 1.2.3 到 1.2.4 通常不应该要求改业务代码，1.2.3 到 1.3.0 通常是兼容新增能力，1.2.3 到 2.0.0 则要默认存在破坏性变更。
但版本号不是合同执行器。维护者可能误发破坏性 patch，依赖链里的间接依赖也可能带来行为变化。所以团队升级时仍要看 changelog、release note、issue、lockfile diff 和测试结果。
面试里更稳的回答是把 SemVer 当作“风险分层工具”：它能帮助安排评审和验证强度，但不能替代真实兼容性验证。
代码示例
可以按版本位数快速判断默认风险，再决定验证强度。
Text
1.2.3 -> 1.2.4 patch: 兼容修复，低风险但仍要跑核心测试
1.2.3 -> 1.3.0 minor: 兼容新增，中等风险，要看新增行为和依赖 diff
1.2.3 -> 2.0.0 major: 可能破坏，高风险，要读迁移指南并准备回滚常见误区
- 认为 patch 一定没有风险，升级后不跑测试。
- 看到 major 就只说“不兼容”，但讲不清要检查哪些破坏点。
- 只看 package.json 版本范围，不看 lockfile 实际解析到了什么版本。