腾讯云nodejs12版本

腾讯云函数（SCF）控制台里，腾讯Node.js 12 的版本运行时选项还在，但旁边已经多了一行灰色小字：“该版本已停止维护”。腾讯点进去创建函数，版本依然能跑，腾讯只是版本官方不再提供安全补丁和底层更新。我第一次注意到这个细节，腾讯是版本在帮一个做小程序后端的朋友排查内存泄漏的时候。他的腾讯函数跑在 Node.js 12 上，日志里偶尔冒出 `MaxListenersExceededWarning`，版本换了 Node.js 16 就没了。腾讯问题不在代码，版本在运行时本身。腾讯

Node.js 12 是版本 2019 年 4 月发布的，2022 年 4 月就结束了官方生命周期。腾讯腾讯云把它保留在 SCF 里，更多是给存量业务一个缓冲期。新项目如果还选它，等于主动放弃 V8 引擎的后续优化、npm 生态里大量要求 Node 14+ 的包，以及 OpenSSL 的安全修复。有个做图像处理的用户跟我聊过，他的函数用 `sharp` 库，Node 12 下安装依赖经常编译失败，换成 Node 16 后一次过。这不是腾讯云的问题，是上游社区不再为老版本提供预编译二进制。

腾讯云 SCF 对 Node.js 12 的支持方式很具体：你仍然可以用控制台、CLI 或 Serverless Framework 部署，触发器、层、环境变量这些功能都正常。但冷启动速度明显比 Node 16 慢一截。我实测过一个 128MB 内存的简单函数，Node 12 冷启动平均 1.2 秒，Node 16 是 0.8 秒左右。差异来自 V8 的启动快照和更高效的模块加载。如果你做的是 API 网关后面的同步接口，这个差距用户能感觉到。

那为什么还有人留在 Node.js 12？我见过两种典型情况。一种是依赖了某个只在 Node 12 上能编译的 C++ 原生模块，升级成本太高，团队选择先冻结版本。另一种更常见：项目是 2020 年写的，之后没人动过，函数一直跑得好好的，直到某天收到腾讯云的邮件提醒“建议升级运行时”。这时候才去看代码，发现 `package.json` 里锁了一堆老依赖，`node-gyp` 版本也对不上。升级不是改一行配置的事，得重新梳理依赖树。

腾讯云其实给了迁移路径。SCF 支持在同一函数里切换运行时，但不会自动帮你改代码。Node 12 到 Node 16 有几个破坏性变更：`fs.promises` 的 API 微调、`Buffer` 构造函数的弃用警告变成错误、`url.parse` 的行为差异。我建议的做法是，先在本地用 Node 16 跑一遍单元测试，再把函数部署到 SCF 的 Node 16 运行时，用别名做灰度。别直接改生产函数的运行时，冷启动期间新旧实例混跑，日志会乱。

有个细节值得说：腾讯云 SCF 的 Node.js 12 运行时里，`npm` 版本是 6.x，而 Node 16 自带 npm 8。npm 6 对 `peerDependencies` 的处理很宽松，npm 8 会严格报错。很多升级失败就卡在这里——本地开发用 npm 8 没问题，因为依赖已经装好了；一到云端重新安装，npm 8 发现某个老包的 peer 依赖不满足，直接构建失败。解决办法是在 `package.json` 里加 `overrides` 字段，或者干脆用 `npm install --legacy-peer-deps`。但 SCF 的构建阶段不让你传这个参数，得靠 `.npmrc` 文件。

如果你现在还在用 Node.js 12 跑腾讯云函数，先别急着升。打开控制台，看函数的“监控”页，查一下最近一周的调用次数和错误率。如果调用量很低，比如每天几百次，直接新建一个 Node 16 的函数，把代码复制过去，改改入口，测试通过后切流量。如果调用量很大，或者依赖复杂，那就排期做依赖审计。Node 12 不会明天就挂，但每多跑一天，你离安全更新和社区支持就更远一步。腾讯云保留它，是情分；你继续用它，是风险。