Vercel Go 运行时固定使用provided.al2023Lambda 运行时从主机检测到确定性的变更解析【免费下载链接】vercelDevelop. Preview. Ship.项目地址: https://gitcode.com/gh_mirrors/ve/vercel本文围绕 Vercel 开源仓库中vercel/go构建器的运行时选择变更展开Go 函数现在始终以provided.al2023作为 Lambda 自定义运行时为目标不再从构建主机的/etc/os-release推断。文中将结合 .changeset/go-provided-al2023.md 变更说明与 packages/build-utils/src/provided-runtime.ts、packages/go/src/index.ts 等源码讲清变更背景、问题根因、底层实现与对开发者构建、部署流程的实际影响帮助你理解为什么预构建prebuiltGo 部署会因此修复。变更速览发生了什么.changeset/go-provided-al2023.md是一份典型的 changeset 变更记录声明了对vercel/go包的patch补丁级变更Go functions now always target theprovided.al2023Lambda runtime. Previously the runtime was detected from the build hosts/etc/os-release, so runningvercel buildon an Amazon Linux 2 machine emittedprovided.al2and the resulting prebuilt deployment failed at deploy time.核心信息有三条新行为Go 函数构建产物固定输出provided.al2023运行时标识旧行为运行时从构建主机的/etc/os-release文件动态检测问题场景在 Amazon Linux 2AL2机器上执行vercel build会生成provided.al2该预构建部署在最终部署阶段失败。背景知识什么是provided系列 Lambda 运行时AWS Lambda 的自定义运行时custom runtime使用provided前缀标识。它允许你自带语言运行时Lambda 执行环境负责拉起你的可执行文件并转发事件provided.al2基于 Amazon Linux 2 的自定义运行时provided.al2023基于 Amazon Linux 2023AL2023的自定义运行时。AL2023 是 AWS 新一代的 Amazon Linux 基线相比 AL2 提供了更新的内核、工具链和安全基线。从仓库中 packages/build-utils/src/collect-build-result/validate-build-result.ts 的SUPPORTED_AL2023_RUNTIMES列表可以看到当前构建体系在 AL2023 镜像上认可的运行时集合为export const SUPPORTED_AL2023_RUNTIMES [ nodejs20.x, nodejs22.x, nodejs24.x, provided.al2023, python3.12, python3.13, python3.14, ruby3.3, bun1.x, executable, ] as const;注意该列表中不包含provided.al2。这正是旧行为会在预构建部署时失败的根源——构建输出声明的运行时provided.al2与部署环境AL2023 构建镜像支持的运行时集合不匹配。旧行为的问题运行时随构建主机漂移在本次变更之前Go 构建器输出的运行时标识取决于执行vercel build的那台机器在 Amazon Linux 2 机器上构建 → 输出provided.al2在 Amazon Linux 2023、Ubuntu、macOS 或任意 CI 机器上构建 → 输出可能是其他检测结果。这在“本地构建 上传产物部署”的预构建prebuilt工作流中尤其危险。vercel build可以在开发者笔记本、自建 CI、GitHub Actions 等多种环境上执行而构建产物中声明的 Lambda 运行时必须与远端部署目标匹配。当你在 AL2 机器上预构建 Go 函数时产物携带provided.al2但部署端基于 AL2023 的运行时校验见上文的SUPPORTED_AL2023_RUNTIMES会将其判定为非法导致部署失败。换句话说构建时的机器环境决定了部署时能否成功这是明显的环境耦合问题。新实现的源码解析运行时变成编译期常量本次变更的核心修复位于 packages/build-utils/src/provided-runtime.ts。整个实现非常简洁/** * The Lambda runtime that custom runtimes must target. * * Builds run on Amazon Linux 2023, so this is a constant. It is deliberately * not derived from the build hosts /etc/os-release: vercel build also runs * on developer machines and in CI, and the emitted runtime has to match the * deploy target rather than wherever the build happened to run. * * This stays a function so that custom runtimes pick up any future base image * migration without having to change their own code. */ export async function getProvidedRuntime(): Promiseprovided.al2023 { return provided.al2023; }关键设计决策可以从源码注释中直接读出固定为常量由于构建本身运行在 Amazon Linux 2023 镜像上运行时标识就是确定的provided.al2023无需任何运行时探测刻意不读取/etc/os-releasevercel build同样会跑在开发者机器和 CI 上产物中的运行时必须匹配部署目标而不是匹配“构建碰巧发生在哪里”保留为 async 函数而非裸常量这样未来若基础镜像再次迁移所有调用方包括自定义运行时无需改动自身代码即可继承新值。Go 构建器如何消费该运行时在 packages/go/src/index.ts 的build()流程末尾Go 构建器把编译产物包装成 Lambda 对象时使用了该函数const runtime await getProvidedRuntime(); const lambda new Lambda({ files: { ...(await glob(**, outDir)), ...includedFiles }, handler: HANDLER_FILENAME, runtime, runtimeLanguage: go, supportsWrapper: true, environment: {}, });几个值得注意的细节handler为HANDLER_FILENAME即bootstrap${OUT_EXTENSION}见同文件 packages/go/src/index.ts——这是provided.*自定义运行时的约定可执行文件名由 packages/go/src/go-helpers.ts 中go build的输出路径决定runtimeLanguage: go标记运行时语言supportsWrapper: true表明该 Lambda 支持 wrapper 包装机制。由此无论构建发生在什么操作系统或发行版上Go 函数的产物始终声明provided.al2023与部署端 AL2023 基线保持一致。变更的影响面与开发者视角谁受影响使用 Go 编写 Vercel Serverless Functions 的开发者构建流程对他们是透明的部署稳定性得到提升自定义运行时维护者若你的自定义运行时调用了getProvidedRuntime()会自动获得provided.al2023无需修改代码在非 AL2023 机器如 AL2、Ubuntu、macOS上执行vercel build的用户此前可能因运行时漂移在部署阶段失败现在行为统一。需要做什么对绝大多数开发者来说无需任何迁移操作。你只需要照常编写 Go 入口文件例如api/index.go导出处理函数可选地在项目根放置go.mod指定 Go 版本Go 版本选择逻辑见 packages/go/src/go-helpers.ts优先解析go.mod中的版本否则使用版本映射表中最新的受支持版本执行vercel build或直接vercel deploy即可。构建产物中的运行时标识现在与部署目标强一致预构建产物不再因运行时声明不匹配而失败。如何验证如果你想确认自己构建的 Go 函数使用了正确的运行时可以检查构建产物目录中 Lambda 配置信息中声明的 runtime 值应当为provided.al2023。仓库中 packages/go/test 下的集成测试与 examples 中的 Go 示例如examples/gin、examples/axum之外的 Go 框架用例可用于端到端验证构建产物。相关机制补充版本解析与缓存本次变更只涉及运行时标识不影响 Go 工具链版本解析。从 packages/go/src/go-helpers.ts 可以看到构建器会按以下优先级定位 Go 工具链项目本地缓存.vercel/cache/golang全局缓存~/.cache/com.vercel.com/golang系统PATH。若均未命中则下载安装到全局缓存并软链到本地缓存便于prepareCache持久化。版本偏好来自go.mod中的toolchain或go指令否则取版本映射表中最新的受支持版本。这些机制与运行时标识解耦可独立演进。小结vercel/go的这次 patch 变更本质上把 Lambda 运行时标识从“构建时探测”重构为“部署目标常量”源码 packages/build-utils/src/provided-runtime.ts 中的getProvidedRuntime()不再读取/etc/os-release而是固定返回provided.al2023。这让vercel build的产物在任何构建主机上都保持一致的运行时声明修复了在 Amazon Linux 2 机器上预构建 Go 函数导致部署失败的问题也为未来基础镜像迁移保留了单一改动点。【免费下载链接】vercelDevelop. Preview. Ship.项目地址: https://gitcode.com/gh_mirrors/ve/vercel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Vercel Go 运行时固定使用 `provided.al2023` Lambda 运行时：从主机检测到确定性的变更解析
Vercel Go 运行时固定使用provided.al2023Lambda 运行时从主机检测到确定性的变更解析【免费下载链接】vercelDevelop. Preview. Ship.项目地址: https://gitcode.com/gh_mirrors/ve/vercel本文围绕 Vercel 开源仓库中vercel/go构建器的运行时选择变更展开Go 函数现在始终以provided.al2023作为 Lambda 自定义运行时为目标不再从构建主机的/etc/os-release推断。文中将结合 .changeset/go-provided-al2023.md 变更说明与 packages/build-utils/src/provided-runtime.ts、packages/go/src/index.ts 等源码讲清变更背景、问题根因、底层实现与对开发者构建、部署流程的实际影响帮助你理解为什么预构建prebuiltGo 部署会因此修复。变更速览发生了什么.changeset/go-provided-al2023.md是一份典型的 changeset 变更记录声明了对vercel/go包的patch补丁级变更Go functions now always target theprovided.al2023Lambda runtime. Previously the runtime was detected from the build hosts/etc/os-release, so runningvercel buildon an Amazon Linux 2 machine emittedprovided.al2and the resulting prebuilt deployment failed at deploy time.核心信息有三条新行为Go 函数构建产物固定输出provided.al2023运行时标识旧行为运行时从构建主机的/etc/os-release文件动态检测问题场景在 Amazon Linux 2AL2机器上执行vercel build会生成provided.al2该预构建部署在最终部署阶段失败。背景知识什么是provided系列 Lambda 运行时AWS Lambda 的自定义运行时custom runtime使用provided前缀标识。它允许你自带语言运行时Lambda 执行环境负责拉起你的可执行文件并转发事件provided.al2基于 Amazon Linux 2 的自定义运行时provided.al2023基于 Amazon Linux 2023AL2023的自定义运行时。AL2023 是 AWS 新一代的 Amazon Linux 基线相比 AL2 提供了更新的内核、工具链和安全基线。从仓库中 packages/build-utils/src/collect-build-result/validate-build-result.ts 的SUPPORTED_AL2023_RUNTIMES列表可以看到当前构建体系在 AL2023 镜像上认可的运行时集合为export const SUPPORTED_AL2023_RUNTIMES [ nodejs20.x, nodejs22.x, nodejs24.x, provided.al2023, python3.12, python3.13, python3.14, ruby3.3, bun1.x, executable, ] as const;注意该列表中不包含provided.al2。这正是旧行为会在预构建部署时失败的根源——构建输出声明的运行时provided.al2与部署环境AL2023 构建镜像支持的运行时集合不匹配。旧行为的问题运行时随构建主机漂移在本次变更之前Go 构建器输出的运行时标识取决于执行vercel build的那台机器在 Amazon Linux 2 机器上构建 → 输出provided.al2在 Amazon Linux 2023、Ubuntu、macOS 或任意 CI 机器上构建 → 输出可能是其他检测结果。这在“本地构建 上传产物部署”的预构建prebuilt工作流中尤其危险。vercel build可以在开发者笔记本、自建 CI、GitHub Actions 等多种环境上执行而构建产物中声明的 Lambda 运行时必须与远端部署目标匹配。当你在 AL2 机器上预构建 Go 函数时产物携带provided.al2但部署端基于 AL2023 的运行时校验见上文的SUPPORTED_AL2023_RUNTIMES会将其判定为非法导致部署失败。换句话说构建时的机器环境决定了部署时能否成功这是明显的环境耦合问题。新实现的源码解析运行时变成编译期常量本次变更的核心修复位于 packages/build-utils/src/provided-runtime.ts。整个实现非常简洁/** * The Lambda runtime that custom runtimes must target. * * Builds run on Amazon Linux 2023, so this is a constant. It is deliberately * not derived from the build hosts /etc/os-release: vercel build also runs * on developer machines and in CI, and the emitted runtime has to match the * deploy target rather than wherever the build happened to run. * * This stays a function so that custom runtimes pick up any future base image * migration without having to change their own code. */ export async function getProvidedRuntime(): Promiseprovided.al2023 { return provided.al2023; }关键设计决策可以从源码注释中直接读出固定为常量由于构建本身运行在 Amazon Linux 2023 镜像上运行时标识就是确定的provided.al2023无需任何运行时探测刻意不读取/etc/os-releasevercel build同样会跑在开发者机器和 CI 上产物中的运行时必须匹配部署目标而不是匹配“构建碰巧发生在哪里”保留为 async 函数而非裸常量这样未来若基础镜像再次迁移所有调用方包括自定义运行时无需改动自身代码即可继承新值。Go 构建器如何消费该运行时在 packages/go/src/index.ts 的build()流程末尾Go 构建器把编译产物包装成 Lambda 对象时使用了该函数const runtime await getProvidedRuntime(); const lambda new Lambda({ files: { ...(await glob(**, outDir)), ...includedFiles }, handler: HANDLER_FILENAME, runtime, runtimeLanguage: go, supportsWrapper: true, environment: {}, });几个值得注意的细节handler为HANDLER_FILENAME即bootstrap${OUT_EXTENSION}见同文件 packages/go/src/index.ts——这是provided.*自定义运行时的约定可执行文件名由 packages/go/src/go-helpers.ts 中go build的输出路径决定runtimeLanguage: go标记运行时语言supportsWrapper: true表明该 Lambda 支持 wrapper 包装机制。由此无论构建发生在什么操作系统或发行版上Go 函数的产物始终声明provided.al2023与部署端 AL2023 基线保持一致。变更的影响面与开发者视角谁受影响使用 Go 编写 Vercel Serverless Functions 的开发者构建流程对他们是透明的部署稳定性得到提升自定义运行时维护者若你的自定义运行时调用了getProvidedRuntime()会自动获得provided.al2023无需修改代码在非 AL2023 机器如 AL2、Ubuntu、macOS上执行vercel build的用户此前可能因运行时漂移在部署阶段失败现在行为统一。需要做什么对绝大多数开发者来说无需任何迁移操作。你只需要照常编写 Go 入口文件例如api/index.go导出处理函数可选地在项目根放置go.mod指定 Go 版本Go 版本选择逻辑见 packages/go/src/go-helpers.ts优先解析go.mod中的版本否则使用版本映射表中最新的受支持版本执行vercel build或直接vercel deploy即可。构建产物中的运行时标识现在与部署目标强一致预构建产物不再因运行时声明不匹配而失败。如何验证如果你想确认自己构建的 Go 函数使用了正确的运行时可以检查构建产物目录中 Lambda 配置信息中声明的 runtime 值应当为provided.al2023。仓库中 packages/go/test 下的集成测试与 examples 中的 Go 示例如examples/gin、examples/axum之外的 Go 框架用例可用于端到端验证构建产物。相关机制补充版本解析与缓存本次变更只涉及运行时标识不影响 Go 工具链版本解析。从 packages/go/src/go-helpers.ts 可以看到构建器会按以下优先级定位 Go 工具链项目本地缓存.vercel/cache/golang全局缓存~/.cache/com.vercel.com/golang系统PATH。若均未命中则下载安装到全局缓存并软链到本地缓存便于prepareCache持久化。版本偏好来自go.mod中的toolchain或go指令否则取版本映射表中最新的受支持版本。这些机制与运行时标识解耦可独立演进。小结vercel/go的这次 patch 变更本质上把 Lambda 运行时标识从“构建时探测”重构为“部署目标常量”源码 packages/build-utils/src/provided-runtime.ts 中的getProvidedRuntime()不再读取/etc/os-release而是固定返回provided.al2023。这让vercel build的产物在任何构建主机上都保持一致的运行时声明修复了在 Amazon Linux 2 机器上预构建 Go 函数导致部署失败的问题也为未来基础镜像迁移保留了单一改动点。【免费下载链接】vercelDevelop. Preview. Ship.项目地址: https://gitcode.com/gh_mirrors/ve/vercel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考