构建成功但部署检查失败——这是平台检测和本地构建产物不一致的典型症状。EdgeOne Pages（Makers 用的部署链路）的 Next.js 支持按三个方向查：1. 先看检测的完整报错（决定方向）：页面输出的 vinext 检查失败信息里通常带具体的 diff 内容（缺少文件/多余文件/配置不一致）。没有具体 diff 的话，在构建日志（部署详情-构建日志）里搜 vinext 或 validate 关键字，看检测器的具体输出；2. 最常见的三个根因：a. 输出模式不匹配——Next.js 项目要选对 output 模式：静态导出（output: export 生成 out 目录）还是 Node 服务（需要 SSR runtime）。EdgeOne Pages 对 Next.js 的支持形态决定检测项：如果你的项目是 SSR/ISR（有 getServerSideProps 或中间件），但平台当静态站检查（期望 out 目录），vinext 检测会报缺少服务产物。检查 next.config 的 output 配置和实际构建产物目录（out 还是 .next）是否与平台选择的框架预设一致；b. 锁文件依赖漂移——本地和 CI 的依赖版本差异导致构建产物不同（比如本地 Next 14，CI 装了 15——package-lock 是否提交且 CI 用 npm ci 而非 npm install）。确认平台构建时用的包管理器和 Node 版本（EdgeOne Pages 的构建环境 Node 版本在环境变量或构建配置里设，低版本 Node 下 Next 15 的构建产物会异常）；c. monorepo 的路径问题——workspace 里的 Next 项目不在仓库根目录时，检测器可能在错误的目录找产物（构建命令的工作目录配置）。把构建命令里显式 cd 到正确目录并确认输出目录配置；3. 快速自证路径：本地用与平台一致的命令全量跑一遍构建（删 node_modules 重装），把本地产物和平台部署日志里检测的产物清单对比——差异文件就是问题所在。本地构建产物如果平台检测仍不认，直接提工单带：仓库地址、构建命令、平台报错的完整截图（vinext 的 diff 部分）——平台侧的检测规则细节只有官方能确认（可能是预设配置的问题而不是你的项目问题）。... 展开详请

「Middleware execution failed: a is not a function」基本可以锁定是 proxy.ts 的导出方式问题。Next 16 的运行时要求这个文件必须导出一个函数，常见错误是导出了函数调用结果而不是函数本身，打包压缩后就变成 a is not a function。检查文件末尾的 export default handler 或 export function proxy；另外 middleware.ts 和 proxy.ts 同时存在时 middleware 会被忽略，只留一个。本地 next start 复现一遍，报错会直接指到位置。... 展开详请