npm 版本总出错？用 semver 语义化规则管理包发布的 3 类版本号

1. 版本号不是“随便加一”的数字，而是团队协作的契约语言我见过三个项目在同一天因为npm version patch命令执行后，CI 流水线集体报错：一个依赖包的peerDependencies突然不满足，另一个下游服务在安装时提示UNMET PEER DEPENDENCY，第三个直接在构建阶段抛出TypeError: xxx is not a function。排查了两小时才发现——上游包把一个破坏性变更塞进了patch版本里，只因开发者觉得“只是改了个参数默认值”。这不是偶然。npm 的版本号本身不带语义，它只是一串字符串。真正赋予它意义的，是semver（Semantic Versioning）规范——一套用三位数字（MAJOR.MINOR.PATCH）编码变更意图的协议。而问题在于：绝大多数人把它当成了“自动递增计数器”，而不是“接口契约说明书”。更麻烦的是，在 AI 编程工具深度介入开发流程的今天，这个契约正在被悄悄瓦解。你让 AI 工具基于一段旧文档生成package.json，它可能直接写"version": "1.0.0"；你让它修复一个类型错误，它顺手把@types/node升到20.x，却没意识到这会触发 TypeScript 5.0 的严格检查规则；你让它补全peerDependencies，它抄了隔壁项目的写法，但那个项目用的是 React