先说结论
「我本地能跑、你那边报错」在 Node 项目里，十之八九是版本不一致。
最小组合拳只要两行配置习惯：
这和 GitHub / GitCode 无关，但 开源贡献者 clone 下来第一件事就是对齐环境——对齐成本越低，PR 越多。
前提： 下文以 Node 18+ / npm 与 pnpm 通用概念 为主；具体 CLI 以你团队安装的 nvm / fnm / volta 为准。
一、.nvmrc 放什么
示例（择一风格，团队统一即可）：
20
表示默认使用 Node 20 最新 LTS 线；也可以写完整版本：
20.11.0
进入目录后（nvm 用户）：
nvm use
若未安装对应版本，按 nvm 提示 nvm install 即可。
二、package.json 的 engines 字段
{
"engines": {
"node": ">=20.0.0 <21"
}
}
含义：声明支持的 Node 范围。
注意：默认情况下 npm 不会因为 engines 不匹配就拒绝安装（行为因版本和配置而异）；pnpm / yarn 有更明确的约束选项。
pnpm 示例（在 package.json 顶层）
{
"packageManager": "pnpm@9.12.0",
"engines": {
"node": ">=20.0.0"
}
}
团队统一 packageManager 可减少「锁文件不一致」类扯皮。
三、CI 里要对齐两样东西
否则本地锁了版本，CI 仍可能用错镜像：
GitHub Actions 常见写法是用官方 actions/setup-node，并在文档里写清楚 node-version-file: '.nvmrc'（若使用）。
四、和「开源贡献」怎么一句话说清楚
在 CONTRIBUTING.md 加一小节即可：
## 环境
– 使用 Node 版本见 `.nvmrc`
– 安装依赖：pnpm i（或 npm ci）
新人第一次提 PR 时，少踩一半沟通坑。
五、常见反模式
- 口头约定「我们都用 Node 20」——新人第一次就会忘。
- 只锁 engines 不锁包管理器——锁文件冲突照样发生。
- CI 用 latest Node——和本地 LTS 不一致，半夜构建红了都不知道为啥。
总结
.nvmrc 解决 「我默认该用哪版 Node」；engines 解决 「哪些版本官方支持」。
两样一起做，再加 CI 对齐，才算闭环。
你们现在是用 nvm、fnm 还是 volta？
