Next.js 維護指南：2026 年版本

我從 Next.js 版本 9 開始維護應用程式。其中一些應用程式至今仍在生產環境中運行，每天服務數百萬個請求。其他的呢？它們變成了升級的噩夢，因為某人（有時是我）在六個月內跳過了維護，突然面臨 47 個主要版本的碰撞、三個已棄用的 API，以及一個讓安全團隊失眠的 CVE。

Next.js 發展迅速。該框架在 2024 年和 2025 年期間大約每六個月推出一個主要版本，2026 年繼續這個速度。如果你沒有積極維護 Next.js 項目，你會累積技術債務，其速度比預期的要快得多。本指南涵蓋了我在保持 Next.js 應用程式健康方面學到的一切，從每週的依賴項檢查到年度主要版本遷移。如果你已經知道需要幫助，提交你的 RFP，我們會看一下。

目錄

為什麼 Next.js 維護比你想像的更重要

讓我用一些數字來說明。根據 Snyk 的 2025 年開源安全狀態報告，平均 JavaScript 項目有 49 個直接依賴項和超過 500 個傳遞依賴項。每一個都是潛在的攻擊面。2025 年，漏洞發佈和利用在野外出現之間的中位時間下降到 7 天。七天。

Next.js 特別引入了原生 React 應用程式沒有的維護考慮：

  • 伺服器端渲染攻擊面 -- 你的 Next.js 應用程式在伺服器上運行代碼，而不僅僅是在瀏覽器中。伺服器端的易受攻擊的依賴項遠比瀏覽器中沙盒化的危險得多。
  • API 路由和 Server Actions -- 這些是完整的後端端點。它們需要與任何 Express 或 Fastify API 相同的安全嚴謹度。
  • 構建管道依賴項 -- SWC、webpack/Turbopack、PostCSS 處理器和圖像優化都有自己的依賴項樹。
  • 中間件執行 -- 在許多部署中在邊緣運行，具有自己的一套兼容性和安全考慮。

除了安全性外，還有 SEO 角度。Google 的核心網絡指標是排名因素，Next.js 性能衰退來自過時的代碼可能會直接影響你的搜索可見性。我們在 Social Animal 的客戶僅通過從 Next.js 13 升級到 15 並修復累積的性能問題就恢復了 15-20% 的丟失有機流量。

建立一個實際可行的維護計劃

我在維護數十個 Next.js 項目後得到的關鍵見解：當維護枯燥乏味且例行時，維護會更容易。它變成「項目」的那一刻，就是它已經逾期的時刻。

以下是我使用的計劃：

頻率 任務 時間估計
每週 審查 Dependabot/Renovate PR，合併修補程式更新 30-60 分鐘
雙週 運行 npm audit 並處理發現 30 分鐘
每月 更新次要版本，審查更新日誌以了解破壞性變更 2-4 小時
每季度 審計未使用的依賴項，審查包大小，更新 Node.js 4-8 小時
每個版本 主要 Next.js 版本遷移 8-40 小時
每年 完整安全審計、依賴項檢查、基礎設施審查 16-40 小時

每週的節奏

每個星期一早上，我檢查 Renovate 或 Dependabot 等工具打開的自動化 PR。修補程式更新（1.2.3 → 1.2.4）在 CI 通過後合併。這最多花 30 分鐘，可以防止「200 個過時包」的情況。

# 我每週運行的快速健康檢查
npx npm-check-updates --target patch
npm audit --audit-level=moderate
npx next info

每月深度檢查

每月一次，我查看次要版本碰撞。這些可能包括新功能，但不應破壞現有 API。強調「不應該」。始終閱讀更新日誌。

# 檢查次要更新
npx npm-check-updates --target minor

# 預覽會發生什麼變化
npx npm-check-updates --target minor --format group

我將相關更新分組在一起。單獨更新 @next/font 而不是 next 是在自找麻煩。它們應該同步移動。

依賴項升級：分步流程

這是大多數團隊出錯的地方。他們運行 npm update，祈禱，然後推送。以下是我實際做的：

步驟 1：了解你擁有的東西

在升級任何東西之前，了解你的依賴項景觀。

# 列出所有過時的包以及詳細信息
npm outdated

# 為特定包生成依賴項樹
npm ls react-dom

# 檢查鎖定文件中的重複項
npx depcheck

步驟 2：按風險對更新進行分類

並非所有更新都是平等的。我將它們分為不同的類別：

風險等級 示例 方法
低 修補程式更新、僅開發依賴項、類型定義更新 批量合併
中 運行時依賴項中的次要版本碰撞、Next.js 修補程式更新 單獨更新，運行完整測試套件
高 主要版本碰撞、Next.js 次要/主要更新、React 更新 專用分支、徹底測試、分階段推出
關鍵 運行時依賴項的安全修補程式 同日更新、緊急流程

步驟 3：建立隔離分支

對於任何超出修補程式更新的內容：

git checkout -b deps/update-2026-05

# 更新特定包
npm install next@latest react@latest react-dom@latest

# 立即運行構建 -- 不要等待
npm run build

# 運行你的測試套件
npm test

# 檢查類型錯誤（如果使用 TypeScript）
npx tsc --noEmit

步驟 4：驗證運行時行為

我們去年在客戶站點遇到了這個問題：構建通過了，測試是綠色的，紙面上一切看起來都很好。然後 Server Components 開始在生產環境中拋出水合不匹配，因為依賴項已在次要碰撞中更改了其輸出格式。通過的構建和測試並不意味著一切都有效。

我總是：

  1. 運行開發伺服器並手動點擊關鍵路徑
  2. 檢查 Server Components 是否仍正確呈現（水合不匹配喜歡隱藏）
  3. 驗證 API 路由返回預期的回應
  4. 測試中間件行為，尤其是身份驗證流程
  5. 檢查圖像優化是否仍有效（next/image 組件在更新中已損壞）

如果你正在中途進行這類工作的範圍界定，需要你身後的團隊，發送你的 RFP，我們可以弄清楚正確的方法。

步驟 5：部署後監控

不要合併後忘記。在部署依賴項更新後的 48 小時內監控你的錯誤跟蹤（Sentry、LogRocket）和性能監控。

2026 年 Next.js 的安全加固

Next.js 的安全性已經顯著演變。Next.js 14 中引入並在 15 和 16 中成熟的 Server Actions 模型完全改變了攻擊面。以下是現在要關注的。

Server Action 安全性

Server Actions 基本上是公共 API 端點。這樣對待它們。

// 不好 -- 無驗證，無身份驗證檢查
'use server'
export async function deleteUser(userId: string) {
  await db.user.delete({ where: { id: userId } })
}

// 好 -- 經過驗證、經過身份驗證、已授權
'use server'
import { z } from 'zod'
import { auth } from '@/lib/auth'

const deleteUserSchema = z.object({
  userId: z.string().uuid(),
})

export async function deleteUser(rawData: unknown) {
  const session = await auth()
  if (!session?.user) throw new Error('Unauthorized')
  
  const { userId } = deleteUserSchema.parse(rawData)
  
  // 檢查用戶是否有權刪除此特定用戶
  if (session.user.role !== 'admin') throw new Error('Forbidden')
  
  await db.user.delete({ where: { id: userId } })
  revalidatePath('/admin/users')
}

安全標頭

你的 next.config.js（或 2026 年中的 next.config.ts -- TypeScript 配置自 Next.js 15 以來一直很穩定）應該設置安全標頭：

// next.config.ts
import type { NextConfig } from 'next'

const securityHeaders = [
  { key: 'X-DNS-Prefetch-Control', value: 'on' },
  { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' },
  { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
]

const config: NextConfig = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: securityHeaders,
      },
    ]
  },
}

export default config

內容安全政策

CSP 在 Next.js 中較難，因為有用於水合的內聯指令碼。基於隨機數的方法效果最好：

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const nonce = Buffer.from(crypto.randomUUID()).toString('base64')
  const cspHeader = `
    default-src 'self';
    script-src 'self' 'nonce-${nonce}' 'strict-dynamic';
    style-src 'self' 'nonce-${nonce}';
    img-src 'self' blob: data:;
    font-src 'self';
    object-src 'none';
    base-uri 'self';
    form-action 'self';
    frame-ancestors 'none';
    upgrade-insecure-requests;
  `
  
  const response = NextResponse.next()
  response.headers.set('Content-Security-Policy', cspHeader.replace(/\s{2,}/g, ' ').trim())
  response.headers.set('x-nonce', nonce)
  return response
}

npm 審計工作流

不要只運行 npm audit。系統地處理結果：

# 生成 JSON 報告以進行跟蹤
npm audit --json > audit-report.json

# 修復可以自動修復的內容
npm audit fix

# 對於需要主要碰撞的頑固問題
npm audit fix --force  # 謹慎使用此選項

# 檢查特定包的已知漏洞
npx is-my-node-vulnerable

對於修復尚不可用的包，在 package.json 中使用 npm audit 覆蓋：

{
  "overrides": {
    "vulnerable-transitive-dep": ">=2.1.1"
  }
}

自動化工具和 CI/CD 整合

自動化是分隔維護良好的團隊和維護不好的團隊的原因。這是我 2026 年的堆棧：

Renovate Bot 配置

對於 Next.js 項目，我更喜歡 Renovate 而不是 Dependabot。它的配置性更強，對 monorepo 的支持更好。

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "schedule": ["every weekend"],
  "packageRules": [
    {
      "matchPackageNames": ["next", "react", "react-dom", "@types/react", "@types/react-dom"],
      "groupName": "React + Next.js core",
      "automerge": false
    },
    {
      "matchUpdateTypes": ["patch"],
      "matchPackagePatterns": ["eslint", "prettier", "@types/"],
      "automerge": true,
      "automergeType": "branch"
    },
    {
      "matchPackagePatterns": ["*"],
      "matchUpdateTypes": ["major"],
      "enabled": true,
      "automerge": false,
      "labels": ["major-update", "needs-review"]
    }
  ],
  "vulnerabilityAlerts": {
    "enabled": true,
    "labels": ["security"]
  }
}

依賴項更新的 CI 管道

你的 CI 在依賴項更改時應做的不僅是運行測試：

# .github/workflows/dependency-check.yml
name: Dependency Update Validation
on:
  pull_request:
    paths:
      - 'package.json'
      - 'package-lock.json'

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - run: npm test
      - run: npm audit --audit-level=high
      - name: Bundle size check
        run: npx size-limit
      - name: Lighthouse CI
        uses: treosh/lighthouse-ci-action@v12
        with:
          configPath: './lighthouserc.json'

Socket.dev 用於供應鏈安全

我已將 Socket.dev 添加到我維護的每個項目中。它會捕捉 npm audit 錯過的東西，比如突然在新版本中添加網絡調用或文件系統訪問的包。在過去一年中，它在我工作過的項目中捕捉了兩個可疑的更新。

處理主要 Next.js 版本遷移

主要版本遷移值得有自己的部分，因為它們是最耗時和最危險的維護任務。

遷移冊

  1. 在編寫任何代碼之前完全閱讀官方遷移指南。Vercel 為每個主要版本發佈詳細的代碼模式和指南。

  2. 首先運行代碼模式。 Next.js 提供自動化代碼模式，可處理大多數重命名和 API 變更：

npx @next/codemod@latest upgrade

  1. 修復編譯器錯誤。 在代碼模式運行後，運行 TypeScript 編譯並修復損壞的內容。

  2. 測試 Server Components 和 Client Components 邊界。 主要版本通常改變了有關組件類型的默認行為。

  3. 驗證數據獲取模式。 從 getServerSideProps 轉向 Server Components 是 Next.js 有史以來最大的破壞性變更（Next.js 13）。後續版本繼續在這個領域進行改進。

  4. 更新你的部署配置。 Vercel 會自動處理此問題，但如果你自行託管或使用不同的平台，你需要更新 Dockerfile、構建指令碼或無伺服器配置。

2026 年特定版本的說明

遷移 關鍵變更 估計的工作量（中型應用程式）
Next.js 14 → 15 非同步請求 API、React 19、Turbopack 穩定 16-24 小時
Next.js 15 → 16 更新的快取默認值、React 編譯器整合 8-16 小時

如果你仍在運行 Next.js 13 或更早版本，認真考慮分階段遷移或全新重建是否更有意義。我們在 Social Animal 幫助團隊做出這個決定。有時誠實的答案是「重新開始」。

將性能監控作為維護

維護不僅僅是保持依賴項最新。它是在用戶（和 Google）注意到性能衰退之前捕捉它。

要監控的內容

  • 核心網絡指標：LCP、CLS、INP（交互到下一次繪製在 2024 年替代了 FID）。使用 Vercel Analytics、Google Search Console 或 CrUX 數據。
  • 構建時間：如果你的構建時間在三個月內翻倍，就有問題了。在 CI 中跟蹤它。
  • 包大小：使用 @next/bundle-analyzer 和 size-limit 設置預算。
  • 伺服器回應時間：特別是對於 Server Components 和 API 路由。
  • 錯誤率：更新後的尖峰表示衰退。
# 將包分析添加到你的項目
npm install @next/bundle-analyzer

// next.config.ts
import withBundleAnalyzer from '@next/bundle-analyzer'

const config = withBundleAnalyzer({
  enabled: process.env.ANALYZE === 'true',
})({
  // 你的配置
})

export default config

運行 ANALYZE=true npm run build 每月一次並比較結果。不斷增加的包大小通常指向在次要更新中添加了許多權重的依賴項。

何時重建與何時升級

這是沒有人想要提出的難題。以下是我的決策框架：

在以下情況下升級到位：

  • 你落後 1-2 個主要版本
  • 你的代碼庫遵循現代模式（App Router、Server Components）
  • 測試涵蓋關鍵路徑
  • 團隊理解現有代碼庫

考慮重建的時間：

  • 你落後 3+ 個主要版本
  • 應用程式仍在 Pages Router 上，你需要 App Router 功能
  • 除了依賴項外，還有大量技術債務已累積
  • 原始架構不適合當前要求

考慮遷移到不同框架的時間：

  • 你的網站大多是靜態的，Next.js 是多餘的（查看 Astro）
  • 你在與 Next.js 模式對抗，而不是與其協同工作
  • 你的團隊在不同堆棧中擁有專業知識

如果你正在運行一個有無頭 CMS 的內容豐富的網站，有時 轉向目的構建的架構 比維護一個已演變超出其原始範圍的 Next.js 應用程式節省更多時間。我們總是很樂意 誠實地談論選項。

常見問題

我應該多久更新一次 Next.js 依賴項？ 修補程式更新應該每週進行。它們幾乎總是安全的，通常包含安全修復。次要更新每月一次，在審查更新日誌後。主要版本在穩定版本發佈後 2-3 個月內，一旦生態系統有時間追上。等待超過 6 個月進行主要版本會造成重大升級困難。

使用 npm audit fix --force 安全嗎？ 不，沒有仔細審查的情況下不安全。--force 標誌允許依賴項中的主要版本碰撞，這可能引入破壞性變更。我只是將其用作起點。在分支上運行它，構建、徹底測試，並在合併之前審查 package-lock.json 中的每項更改。對於生產應用程式，手動更新特定的易受攻擊的包幾乎總是更安全的。

2026 年自動化 Next.js 依賴項更新的最佳工具是什麼？ 我 2026 年的首選是 Renovate Bot。它處理分組更新（保持 next、react 和 react-dom 同步），支持低風險更新的自動合併，並具有出色的 monorepo 支持。Dependabot 適用於更簡單的設置。無論你使用哪個更新工具，Socket.dev 都是作為額外層的必需品，以確保供應鏈安全。

我如何在傳遞依賴項中處理安全漏洞？ 首先，檢查更新直接依賴項是否拉入易受攻擊的包修復它。如果沒有，在 package.json（npm）或 resolutions（yarn）中使用 overrides 強制特定版本。作為最後手段，如果易受攻擊的包是你無法更新的包，評估你是否可以完全替換父依賴項或使用 patch-package 添加補丁。

當最新 Next.js 版本發佈時，我應該立即升級嗎？ 不適用於生產應用程式。等待主要版本發佈後的 2-4 週，讓初始一輪錯誤修復進行。遵循 Next.js GitHub 問題和社區 X/Twitter 上的早期問題報告。對於次要和修補程式版本，你可以更積極。這些通常在發佈後幾天內是安全的。

如果我是獨自開發者，我如何維護 Next.js 應用程式？ 自動化是你最好的朋友。設置 Renovate Bot，對修補程式更新進行自動合併，配置 CI 以在每個依賴項 PR 上運行構建和測試，並為每月的手動審查設置固定的 2 小時塊。我概述的計劃適用於獨自開發者。每週檢查變為對自動化 PR 的 15 分鐘瀏覽，每月深度檢查保持在 2 小時。

我應該在 2026 年使用什麼 Node.js 版本與 Next.js？ Next.js 16 需要 Node.js 18.18 或更高版本，但我建議運行 Node.js 22 LTS（於 2024 年 10 月進入 LTS，支持至 2027 年 4 月）。Node.js 20 LTS 也很好。避免 Node.js 18，除非你有特定的兼容性要求。它於 2025 年 4 月達到使用壽命終止，不應再在生產環境中使用。

如果我們有內部開發者，值得為專業維護付費嗎？ 這取決於你的團隊的帶寬和專業知識。內部開發者經常因為功能工作總是感到更緊迫而優先考慮維護之外的工作。如果你的 Next.js 應用程式是業務關鍵的，並且你發現維護工作持續滑落，與專門團隊進行 專項維護安排 確保它實際上完成了。我們看到了很多團隊，其中延遲維護的成本遠遠超過定期專業護理的成本。準備好停止延遲嗎？在 48 小時內獲得提案，讓我們弄清楚你的應用程式需要什麼。