Next.js 多实例偶发 Failed to find Server Action，先核对构建产物

表单页面能打开，提交后却报 Failed to find Server Action，有时刷新又恢复。应用经过负载均衡或刚做过滚动发布时，先记录这次页面来自哪个构建、请求落到哪个实例；一个客户端可能正在调用另一个版本的服务端。

这条错误不单指某一种配置。旧页面引用的 action 不在接收实例的清单里，与实例无法解密 action 捕获的闭包数据，需要分别核对。固定一个密钥不能凭空补出另一份构建中不存在的 action。

把失败请求与实例、版本对应起来

保存完整服务端错误、Next.js 版本、实际构建命令和发布时间。确认用户确实在正常页面上提交了业务表单，再查看对应 action 请求；仅看到一条无法识别 action 的日志，不能证明整个网站存在同一种故障。

使用现有请求追踪记录实例标识和发布版本，比较页面响应与提交响应。不要把表单内容、认证信息、完整环境变量或加密密钥写进诊断日志。若只有特定副本失败，应先比较它与正常副本的构建来源、服务器引用清单及实际配置。

检查部署流程是否在每个副本中分别运行构建、是否只复制了一部分 .next 文件，或把新客户端文件与旧服务器产物混在一起。即便源码提交相同，各次构建也不应未经核对就当作完全相同的可部署产物。

另外保留页面打开时间。某个标签页在发布前就已打开，使用旧 action 标识提交给新服务器，是另一条需要覆盖的路径；新打开页面成功，只能说明新页面与当前服务端配合正常。

优先让同一版本使用同一份完整产物

能由发布系统统一构建时，生成并验收一份完整产物，再部署到所有副本。客户端资源、服务端文件和相应清单应一起推广，不能靠单独覆盖某个 chunk 修补版本关系。

必须分别构建的多实例应用，还要为同一部署环境配置一致的 NEXT_SERVER_ACTIONS_ENCRYPTION_KEY。按 Next.js 的部署规则，在构建阶段注入并保持运行配置一致；它是私有密钥，不应使用 NEXT_PUBLIC_* 名称，也不进入浏览器代码。

密钥使用 base64 表示，解码后长度需满足 AES 的 16、24 或 32 字节要求。生产值应由既有密钥管理流程生成、保存和分发，不复制文章中的示例字符串，也不在每个容器启动时重新生成不同值。

具体版本实现可能读取运行时覆盖值，但运行时才给几份旧产物补变量，不会重新生成它们的全部 action 清单，也不能证明客户端与服务端已对应。

统一密钥解决的是加密配置一致性。它不保证跨环境、跨代码变化或任意旧构建的 action ID 永远相同，也不替代每个 action 原有的认证与权限检查。

旧标签页需要单独安排发布策略

滚动发布期间，旧页面可能碰到新副本。按使用版本核对 deploymentId 及部署平台提供的版本对应能力，设计旧客户端、静态资源和服务端的处理方式；不要把随意设置一个固定 ID 当作所有版本始终兼容的证明。

版本不一致时，Next.js 的相应保护可能触发完整页面导航。需要评估未保存表单、组件状态和用户提示；重新加载页面可以取得新页面，却不保证原来的业务提交已执行或能够安全重复。

涉及支付、创建记录或发送消息的 action，先查业务结果及幂等约定，再决定是否重提。浏览器显示错误不表示服务端一定没有产生副作用，不能在捕获错误后无条件自动重发。

保存原部署配置和完整可用产物。在受控发布中分别检查各副本、跨副本请求、新页面，以及发布前打开的标签页；确认 action 请求取得预期业务结果、服务端版本能对应，且失败时没有重复写入。回退应恢复整套匹配产物和配置，并继续处理已有客户端状态，不能只恢复一份静态文件或临时更换密钥。