我太懂这种本地跑满格、一上云就掉链子的憋屈了！结合你给出的依赖树信息，还有本地正常、云端报错的差异点，我整理了几个针对性的排查和解决思路，你可以挨个试：

1. 先查Docker镜像的构建逻辑，别让依赖在构建时“失踪” #

很多时候问题出在Docker镜像构建的细节上——比如你是不是用了多阶段构建，但不小心把生产环境需要的依赖给漏装了？或者用了npm install --production跳过了dev依赖，但react-scripts构建/运行时其实需要某些webpack相关的依赖（比如schema-utils依赖的ajv）？

排查&修复： #

• 先检查你的Dockerfile，确保构建阶段完整安装了所有依赖（包括devDependencies），再把构建产物复制到运行镜像里。举个标准的React容器化构建示例：

  # 构建阶段：安装全量依赖，完成项目构建
  FROM node:18-alpine as builder
  WORKDIR /app
  COPY package*.json ./
  RUN npm install  # 这里不要加--production！react-scripts构建需要dev依赖支持
  COPY . .
  RUN npm run build
  
  # 运行阶段：只复制构建好的静态文件，用Nginx托管
  FROM nginx:alpine
  COPY --from=builder /app/build /usr/share/nginx/html
  EXPOSE 80
  CMD ["nginx", "-g", "daemon off;"]
  

• 然后强制清理Docker构建缓存，重新构建镜像再推送到ACR：

  docker build --no-cache -t your-acr-repo/your-image:latest .
  docker push your-acr-repo/your-image:latest
  

  旧缓存里可能藏着依赖损坏或缺失的坑，清了重来大概率能解决不少问题。

2. 统一ajv版本，解决依赖版本冲突 #

从你npm list ajv的输出能看到，项目里同时存在ajv@8.13.0和ajv@6.12.6两个版本——本地环境的依赖解析逻辑可能和Azure App Service的运行环境有差异，导致某些场景下找不到对应版本的模块文件。

修复步骤： #

• 先安装npm-force-resolutions工具，用来强制统一项目里的ajv版本：

  npm install -D npm-force-resolutions
  

• 打开你的package.json，添加以下配置：

  "resolutions": {
    "ajv": "8.13.0"
  },
  "scripts": {
    "preinstall": "npx npm-force-resolutions"
  }
  

• 然后彻底清理旧依赖，重新安装：

  rm -rf node_modules package-lock.json
  npm install
  

• 最后重新构建并推送镜像到ACR，再部署到Azure App Service试试。

3. 排查Azure App Service的运行配置&缓存 #

有时候问题不在镜像本身，而是Azure端的配置或缓存搞的鬼：

• 检查启动命令：如果你的镜像用Node.js直接运行（不是Nginx托管静态文件），要确保App Service的启动命令和本地一致（比如npm start）。可以在Azure Portal的「配置」→「通用设置」里确认启动命令。
• 查看详细日志：去App Service的「日志流」里看完整的错误堆栈，说不定能找到触发这个模块缺失的具体环节（比如webpack编译时的某个步骤），能帮你更精准定位问题。
• 清除部署缓存：Azure有时候会缓存旧的部署内容，导致新镜像的依赖没被正确加载。在「部署中心」→「高级选项」里点击「清除」，然后重新部署镜像试试。
• 临时排查资源限制：如果你的App Service用的是免费/基础层SKU，偶尔会因为内存不足导致依赖加载失败。可以临时升级到标准层试试，排除资源不够的可能性（之后再降回来就行）。

先从Docker镜像构建和缓存的排查开始吧，这两个是最常见的触发原因，解决概率最高！

备注：内容来源于stack exchange，提问作者lekocast