【系列主题】Next.js 16 容器化部署深水区踩坑实录第一篇从 Docker 构建失败看依赖隔离多阶段构建的“隐形陷阱”摘要在将 Next.js 项目从本地开发迁移到 Docker 多阶段构建时外部依赖拉取失败和devDependencies丢失是两大高频问题。本文将深入剖析 Docker 构建缓存、网络隔离与 Node.js 依赖管理的冲突并提供一套无感的 Dockerfile 编写范式。1. 背景与痛点我们的项目基于 Next.js 16、Prisma 和 shadcn/ui。为了适应最终 1核2G 的低配生产服务器采用了“高配服务器 Docker 多阶段构建 standalone模式输出”的架构。但在执行docker build时接连遭遇next/font/google拉取超时导致构建中断。明明安装了的 CSS 依赖在构建阶段提示Module not found。2. 坑位一被 GFW 与容器网络双重绞杀的 Google Fonts现象本地运行正常一旦打入 Docker 镜像构建卡死或报网络错误。原理Next.js 的next/font/google在编译时会向 Google 的 CDN 发起请求下载字体文件。在 Docker 构建的沙箱环境中不仅受制于宿主机的网络环境如国内被墙还可能因为 DNS 解析差异导致失败。解决方案将外部运行时请求降级为本地编译时依赖。shadcn/ui 默认使用的Geist字体提供了本地 npm 包。// ❌ 错误写法 (依赖外网)import{GeistSans}fromnext/font/google;// ✅ 正确写法 (依赖本地 node_modules)import{GeistSansasgeistSans}fromgeist/font/sans;同时在 Dockerfile 的依赖安装阶段确保geist被正确安装。3. 坑位二--omitdev导致的“幽灵依赖”现象在 Dockerfile 的deps阶段执行了npm install --omitdev导致后续构建阶段报错找不到 TypeScript、Tailwind 等工具。原理很多开发者为了减小镜像体积会在第一阶段加上--omitdev。但忽略了 Next.js 的next build强依赖devDependencies比如typescript、postcss、tailwindcss。正解在多阶段构建中第一阶段的产物只是给第二阶段Builder用的不应该在第一阶段裁剪依赖。最终的体积控制应该交给 Next.js 的output: standalone它会自动剥离不需要的devDeps。4. 坑位三多次npm install引发的依赖覆盖现象为了安装特定版本的包在 Dockerfile 中先写了RUN npm install geist tw-animate-css --save接着又写了RUN npm install结果包还是丢了。原理第二次npm install会根据当前的package-lock.json重新构建依赖树。如果本地提交的package.json里没有这两个包第二次安装会无情地将它们删掉。终极方案利用 Node.js 脚本在安装前动态篡改package.json确保一次安装成功COPY package.json package-lock.json* ./ # 动态注入依赖防止漏提代码 RUN node -e const fsrequire(fs);const pkgJSON.parse(fs.readFileSync(package.json,utf8));pkg.dependenciesObject.assign({},pkg.dependencies||{},{geist:^1.3.1,tw-animate-css:^1.4.0});fs.writeFileSync(package.json,JSON.stringify(pkg,null,2)); RUN npm install --no-audit --no-fund