📌 项目地址：nodejs/node | ⭐ 118,424 颗星 | 🔧 JavaScript | 📜 未标注
📌 项目地址：nodejs/node | ⭐ 118,424 颗星 | 🔧 JavaScript
nodejs/node 的 README 没有徽章墙，没有 five-minute quickstart。第一段交代定位——开源、跨平台的 JavaScript 运行时——第二段直接进治理模型和版本规则。这份文档假设你已经决定用 Node.js，剩下的篇幅只解决两个会带来实际损失的问题：选错版本，装了没验证的二进制。
4 月和 10 月，把版本分成两种命运
README 里的发布规则可以压成四条：
- Current 线每年 4 月和 10 月各发一个大版本，允许破坏性变更。代码放在对应主版本的分支上，比如 v22.x。
- 只有偶数主版本才成为 LTS。4 月发布的版本在同年 10 月转 LTS；10 月发布的版本支持期只有 8 个月。
- LTS 分两段：12 个月 Active LTS，再加 18 个月 Maintenance，总共 30 个月。期间不加新功能、不做破坏性变更，特殊场景除外。
- LTS 线的代号按字母序排，从 v4 的 Argon 开始。
实际做版本决策时，规则归结成一句话：生产环境别选 10 月发布的版本，8 个月后它就没有支持了。
第三条线是 Nightly：Current 分支每 24 小时构建一次，有代码变动才触发。README 原话是 “Use with caution”。拿它提前测新 API 的兼容性可以，部署就免了。
Current 和 LTS 都遵循语义化版本，每个版本由 Release Team 成员用发布密钥签名。
下载目录的两条别名
官方下载入口提供二进制、安装器和源码包。目录命名有规律可循：
latest/是最新 Current 版本的别名latest-<代号>/指向某条 LTS 线的最新版本
写脚本拉固定版本时，看到 latest-argon 就知道是 v4 那条线。对照代号表即可，不用猜。
验签排在 Download 正下方
README 目录里，Verifying binaries 紧跟在 Download 后面。这个排列顺序本身是一种表态：验证二进制不是可选项。
逻辑不复杂。下载页附带的校验值和文件走同一条通道，通道被污染时两者一起失效。Release Team 的签名密钥独立于下载通道，密钥信息列在 README 的 Release keys 一节。验签是在通道之外建立第二重信任，具体步骤见官方文档对应小节。
治理：边界写在最前面
项目由 OpenJS Foundation 提供支持，采用开放治理模型，细节在 GOVERNANCE.md。README 列出四类角色：TSC（技术指导委员会）、Collaborators、Triagers、以及持有发布密钥的 Release Team。
有一段话出现在 README 开头，位置比贡献指南还靠前：项目鼓励建设性地交换相反意见并妥协，但 TSC 保留限制或阻止反复打击、消耗其他参与者的贡献者的权利。协作有边界，而且这条边界写在最前面，不是藏在行为准则的角落里。项目另有正式的 Code of Conduct。
三个入口，别走错门
- 发现安全漏洞：不要开公开 issue，走 Security 一节指向的流程。
- 使用问题：SUPPORT.md 列了支持渠道。
- 想从源码构建：README 有 Building Node.js 一节。大多数人用官方二进制就够了。
为什么值得读
这份 README 能帮你避开两个损失最大的坑：生产环境跑上了只有 8 个月生命周期的版本，以及部署了没验证过的二进制。
它的写法也值得抄作业：把会造成实际损失的决策信息放在最前面，团队名单和密钥信息全部可查。11.8 万颗星的仓库，通篇没有一句营销话术。