我已經失去計算次數的設計師遞給我一份美麗的 Figma 檔案,說:「建構它應該相當簡單,對吧?」當然,英雄部分看起來很簡單。但隨後你開始深入研究響應式行為、未完全規定的懸停狀態、在幀之間變化的間距,以及存在於設計師頭腦中但代碼中無處可尋的設計系統。Figma 模型和生產級 Next.js 網站之間的差距是項目出現問題的地方。

在 Social Animal 構建了數十個 Figma 轉 Next.js 項目後,我對什麼有效和什麼無效有了強烈的看法。本指南貫穿整個過程——不是理論版本,而是雜亂的真實世界版本,其中設計不完美、利益相關者改變主意,而你需要交付一個在生產中實際表現良好的東西。

Figma to Next.js: The Complete Guide to Turning Designs Into Code

目錄

為什麼選擇 Next.js 進行 Figma 轉代碼項目

你可以將 Figma 設計轉換為普通 HTML。你可以使用 Astro、Remix 或 SvelteKit。那麼為什麼選擇 Next.js?

實踐中有幾個重要原因:

  • React 組件模型直接映射到 Figma 組件。 設計師考慮組件。React 考慮組件。這種對齐並非微不足道——它意味著代碼中的組件樹可以鏡像 Figma 中的組件層級,這使維護變得容易得多。
  • App Router 和服務器組件提供營銷網站和 Web 應用程序都需要的渲染靈活性。靜態頁面?服務器呈現的動態內容?客戶端交互性?你按路線選擇。
  • 圖像優化是內置的。 next/image 組件處理響應式圖像、延遲加載和格式轉換——否則會佔用你許多構建時間的東西。
  • 生態系統龐大。 無論設計要求什麼——身份驗證、表單、動畫、CMS 集成——Next.js 生態系統中都有一個維護良好的解決方案。

我們在大多數 無頭 CMS 開發項目中使用 Next.js,原因正是這些。如果你好奇什麼時候 Astro 可能更合適(提示:內容豐富、交互最少的網站),請查看我們的 Astro 開發頁面。

在編寫任何代碼之前審計 Figma 檔案

這是大多數開發人員跳過的步驟,也是節省最多時間的步驟。在你編寫一行 JSX 之前,花 30-60 分鐘審計 Figma 檔案。

要檢查的事項

  • 自動布局使用情況。 如果設計師始終使用自動布局,你的生活會變得容易得多。自動布局幾乎 1:1 映射到 Flexbox。如果他們沒有,你將在間距和響應式行為上猜測。
  • 組件一致性。 按鈕是否實際使用共享組件,或者設計師在框架中創建了 14 個略微不同的按鈕變體?打開資源面板並檢查。
  • 命名樣式和變數。 Figma 變數(2023 年發布,到 2025 年廣泛採用)應定義顏色、間距、排版和邊框半徑。如果這些存在,你的設計令牌提取基本上是自動化的。如果沒有,在你開始構建之前標記它。
  • 響應式框架。 設計是否包括移動、平板和桌面斷點?如果只是桌面,在繼續之前你需要與設計師進行對話。
  • 缺失的狀態。 懸停、焦點、活躍、禁用、加載、錯誤、空——檢查交互組件是否具有所有設計的狀態。他們通常沒有。列一份清單。

交接對話

我總是在開始實施之前與設計師安排 30 分鐘的通話。我們共享屏幕 Figma 檔案並走過:

  1. 哪些組件可重用,哪些是一次性的
  2. 響應式行為應該如何工作(不要假設——要問)
  3. 他們心目中的任何動畫或過渡
  4. 來自 CMS 的內容與硬編碼的內容

這次單獨的會議消除了通常困擾設計轉代碼項目的 80% 的往返。

Figma to Next.js: The Complete Guide to Turning Designs Into Code - architecture

從 Figma 提取設計令牌

設計令牌是 Figma 和代碼之間的橋樑。顏色、排版比例、間距單位、邊框半徑、陰影——這些需要系統地提取,而不是憑眼感。

手動提取(小項目)

對於較小的項目,我將使用 Figma 的開發者模式(自 2025 年起,Figma 付費計劃中包含每座位每月 25 美元)直接檢查值。打開開發者模式,點擊任何元素,你會獲得精確的像素值、顏色和字體屬性。

然後我將這些映射到 Tailwind CSS 配置或 CSS 自定義屬性:

// tailwind.config.ts
import type { Config } from 'tailwindcss'

const config: Config = {
  theme: {
    extend: {
      colors: {
        brand: {
          50: '#f0f4ff',
          100: '#dbe4ff',
          500: '#4c6ef5',
          600: '#3b5bdb',
          700: '#364fc7',
          900: '#1c2d7a',
        },
        surface: {
          primary: '#ffffff',
          secondary: '#f8f9fa',
          tertiary: '#f1f3f5',
        },
      },
      fontFamily: {
        sans: ['Inter', 'system-ui', 'sans-serif'],
        display: ['Cal Sans', 'Inter', 'system-ui', 'sans-serif'],
      },
      spacing: {
        '18': '4.5rem',
        '88': '22rem',
      },
      borderRadius: {
        'xl': '1rem',
        '2xl': '1.5rem',
      },
    },
  },
}

export default config

自動化提取(較大的項目)

對於較大的設計系統,使用 Figma 變數 API 或工具如 Tokens Studio(原 Figma Tokens)以結構化格式導出設計令牌。Tokens Studio 可以導出為 Style Dictionary 格式,然後你將其轉換為 Tailwind 配置、CSS 變數或兩者。

管道看起來像這樣:

Figma Variables → Tokens Studio → Style Dictionary → tailwind.config.ts + globals.css

當設計師更新顏色且你需要在代碼庫中傳播它時,此自動化會收回成本。

設置你的 Next.js 項目架構

這是我為每個 Figma 轉 Next.js 構建開始的項目結構:

src/
├── app/
│   ├── layout.tsx
│   ├── page.tsx
│   ├── globals.css
│   └── (routes)/
├── components/
│   ├── ui/           # Primitives: Button, Input, Card, Badge
│   ├── layout/       # Header, Footer, Container, Section
│   ├── sections/     # Hero, Features, Testimonials, CTA
│   └── patterns/     # Composed: PricingCard, TeamMember
├── lib/
│   ├── utils.ts
│   └── fonts.ts
├── styles/
│   └── tokens.css    # Design token CSS variables
└── types/
    └── index.ts

關鍵設置決策

樣式方法: Tailwind CSS 是我對 Figma 轉代碼項目的默認選擇。效用優先的方法意味著我可以將 Figma 的 padding: 24pxgap: 16pxborder-radius: 12px 直接轉換為 p-6 gap-4 rounded-xl,無需上下文切換。如果項目需要 shadcn/ui 等組件庫,Tailwind 已經是基礎。

字體加載: 始終使用 next/font 來自託管字體。這是我的典型設置:

// lib/fonts.ts
import { Inter } from 'next/font/google'
import localFont from 'next/font/local'

export const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-inter',
})

export const calSans = localFont({
  src: '../assets/fonts/CalSans-SemiBold.woff2',
  variable: '--font-display',
  display: 'swap',
})

服務器與客戶端組件: 默認使用服務器組件。僅當你實際需要瀏覽器 API、事件處理程序或 React hooks 時才添加 'use client'。典型的營銷頁面可能有 90% 的服務器組件,配有小型交互島嶼。

構建組件庫

這是大部分工作發生的地方。我的方法:從最小的組件向上工作。

原子組件優先

從 Figma 所謂的「組件」和我們所謂的原始文件開始:

// components/ui/Button.tsx
import { cva, type VariantProps } from 'class-variance-authority'
import { cn } from '@/lib/utils'

const buttonVariants = cva(
  'inline-flex items-center justify-center rounded-xl font-medium transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-brand-500 focus-visible:ring-offset-2 disabled:pointer-events-none disabled:opacity-50',
  {
    variants: {
      variant: {
        primary: 'bg-brand-600 text-white hover:bg-brand-700',
        secondary: 'bg-surface-secondary text-gray-900 hover:bg-surface-tertiary',
        ghost: 'text-gray-600 hover:bg-surface-secondary hover:text-gray-900',
      },
      size: {
        sm: 'h-9 px-3 text-sm',
        md: 'h-11 px-5 text-sm',
        lg: 'h-13 px-7 text-base',
      },
    },
    defaultVariants: {
      variant: 'primary',
      size: 'md',
    },
  }
)

interface ButtonProps
  extends React.ButtonHTMLAttributes<HTMLButtonElement>,
    VariantProps<typeof buttonVariants> {}

export function Button({ className, variant, size, ...props }: ButtonProps) {
  return (
    <button
      className={cn(buttonVariants({ variant, size }), className)}
      {...props}
    />
  )
}

注意變體名稱和大小如何直接映射到 Figma 中存在的內容。如果設計師在 Figma 中有一個按鈕組件,具有「主要」、「次要」和「幽靈」變體——你的代碼應該鏡像這些確切的名稱。

組成部分

構建原始文件後,將其組成頁面部分:

// components/sections/Hero.tsx
import { Button } from '@/components/ui/Button'
import { Container } from '@/components/layout/Container'

export function Hero() {
  return (
    <section className="py-24 md:py-32">
      <Container>
        <div className="mx-auto max-w-3xl text-center">
          <h1 className="font-display text-4xl tracking-tight text-gray-900 md:text-6xl">
            Turn your designs into
            <span className="text-brand-600"> production websites</span>
          </h1>
          <p className="mt-6 text-lg leading-relaxed text-gray-600">
            We build fast, accessible Next.js websites from your Figma files.
          </p>
          <div className="mt-10 flex items-center justify-center gap-4">
            <Button size="lg">Get started</Button>
            <Button variant="secondary" size="lg">Learn more</Button>
          </div>
        </div>
      </Container>
    </section>
  )
}

2025 年 AI 輔助 Figma 轉代碼工具

讓我們談談房間裡的大象:聲稱自動將 Figma 轉換為代碼的 AI 工具。我已經測試了所有主要工具。這是一個誠實的評估。

工具 最適合 代碼質量 框架支持 價格(2025 年)
Fusion (Builder.io) 使用 Builder.io 的 CMS 的團隊 良好——尊重設計系統 React, Next.js, Vue Builder.io 計劃(50 美元+/月)包含
Kombai 想要 AI 輔助編碼的 VS Code 用戶 非常好——生成可編輯的計劃 React, Next.js, Angular 免費級別 + 20 美元/月 Pro
Locofy.ai 快速原型和 MVP 不錯——需要清理 React, Next.js, Gatsby 免費級別 + 8-25 美元/月
Anima 響應式 HTML/React 導出 公平——結構性但不適合生產 React, Vue, HTML 免費級別 + 39 美元/月
Figma to Code Plugin 快速 HTML 片段 基本——良好的起點 HTML, Tailwind 免費
v0 (Vercel) 從描述生成 UI 對於組件很好 React, Next.js 免費級別 + 20 美元/月 Pro

我的誠實看法

這些工具中沒有一個生成我會直接發送到生產環境的代碼而無需進行大量修改。沒有一個。原因如下:

  • 他們生成標記但很少理解你項目的組件架構
  • 他們不知道你的數據獲取模式、CMS 集成或 API 結構
  • 他們經常生成臃腫的 CSS 或不一致的類命名
  • 他們定期錯過無障礙要求

AI 工具真正有幫助的地方: 我使用 Kombai 和 v0 生成初始組件腳手架,尤其是對於複雜的布局。獲得 60-70% 正確的起點可以節省實際時間。我還使用 Cursor,粘貼 Figma 截圖作為上下文,以加快逐節實施。

實際起作用的工作流程:AI 生成粗稿 → 人類開發人員重組、優化和集成 → QA 捕捉不可避免的問題。

如果你正在評估是否自己動手或與代理機構合作,請查看我們的 Next.js 開發功能以了解我們如何處理完整管道。

以正確的方式處理響應式設計

這是 Figma 轉代碼項目通常失敗的地方。設計有桌面模型和移動模型。也許如果你幸運的話還有平板電腦模型。但斷點之間的實際行為?那在任何人的頭腦中都沒有。

移動優先實施

始終先編碼移動並在較大的斷點處添加複雜性:

<div className="grid grid-cols-1 gap-6 md:grid-cols-2 lg:grid-cols-3 lg:gap-8">
  {features.map((feature) => (
    <FeatureCard key={feature.id} {...feature} />
  ))}
</div>

來自 Figma 的常見響應式模式

Figma 模式 CSS/Tailwind 實施
3 列網格 → 在移動設備上堆疊 grid grid-cols-1 md:grid-cols-3
並排 → 反向堆疊 flex flex-col-reverse md:flex-row
在移動設備上隱藏 hidden md:block
不同的字體大小 text-2xl md:text-4xl lg:text-5xl
移動設備上的水平滾動 flex overflow-x-auto md:grid md:grid-cols-4
導航 → 漢堡包 帶有狀態切換的客戶端組件

容器查詢(被低估的強力舉動)

在 2025 年,容器查詢具有出色的瀏覽器支持(全球 95%+)。它們非常適合需要根據其父級寬度而不是視口寬度進行自適應的組件:

@container (min-width: 400px) {
  .card-layout {
    flex-direction: row;
  }
}

Tailwind v4 原生支持 @container 變體的容器查詢。

排版和間距:大多數項目失敗的地方

我估計 60% 的「它看起來不像設計」投訴歸結為排版和間距,而不是布局或顏色。

排版檢查表

  • 字重: Figma 顯示「Semi Bold」,即 font-semibold(600),不是 font-bold(700)。容易出錯。
  • 行高: Figma 使用固定行高(如 28px),Tailwind 使用相對值(如 leading-7)。謹慎轉換。
  • 字母間距: 經常被忽視。Figma 的 -2% 字母間距轉換為 tracking-tight
  • 字體特性: 某些設計使用 OpenType 特性,如製表數字(font-variant-numeric: tabular-nums)或風格替代。檢查 Figma 文本屬性面板。

間距系統

如果設計師使用了 8px 網格(大多數人在 2025 年都這樣做),你的生活很容易——Tailwind 的默認間距比例已經基於 4px 增量。p-4 = 16px,p-6 = 24px,p-8 = 32px。

但要注意不規則的間距。如果設計在某個地方有 20px 填充,那就是 Tailwind 中的 p-5(即 20px)。如果有 18px——這比你想像的更常見——你要麼舍入到最近的步驟,要麼擴展你的間距比例。

圖像、圖標和資源管道

圖像

始終對光柵圖像使用 next/image

import Image from 'next/image'

<Image
  src="/hero-image.webp"
  alt="Product dashboard showing analytics"
  width={1200}
  height={800}
  priority  // Add for above-the-fold images
  className="rounded-2xl"
/>

以 2 倍解析度從 Figma 導出圖像以用於視網膜顯示。使用 WebP 格式。對於英雄圖像,我通常以 2400x1600 導出,讓 next/image 處理響應式調整大小。

圖標

不要將圖標導出為圖像。使用圖標庫或內聯 SVG:

  1. Lucide React ——我的默認選擇。乾淨、一致、1000+ 圖標。樹搖。
  2. Heroicons ——如果設計使用 Heroicons 很好(使用 Tailwind UI 設計的常見)。
  3. 自定義 SVG ——對於特定於品牌的圖標,從 Figma 導出為 SVG 並創建 React 組件。
import { ArrowRight, Check, X } from 'lucide-react'

<ArrowRight className="h-5 w-5" />

動畫和交互

Figma 的原型模式顯示過渡和交互,但將這些轉換為代碼需要解釋。

CSS-First 動畫

對於簡單的懸停效果和過渡,堅持使用 CSS:

<button className="transform transition-all duration-200 hover:scale-105 hover:shadow-lg">
  Get Started
</button>

複雜動畫的 Framer Motion

對於滾動觸發的動畫、頁面過渡或複雜的序列:

'use client'

import { motion } from 'framer-motion'

export function FadeInSection({ children }: { children: React.ReactNode }) {
  return (
    <motion.div
      initial={{ opacity: 0, y: 20 }}
      whileInView={{ opacity: 1, y: 0 }}
      viewport={{ once: true, margin: '-100px' }}
      transition={{ duration: 0.5, ease: 'easeOut' }}
    >
      {children}
    </motion.div>
  )
}

記住:這必須是客戶端組件。保持動畫包裝器瘦弱,盡可能將服務器組件作為子項傳遞。

連接到無頭 CMS

大多數從 Figma 設計構建的營銷網站至少需要一個 CMS 來處理某些內容。這是 無頭 CMS 開發變得至關重要的地方。

我最常用於 Next.js App Router 的模式:

// app/blog/[slug]/page.tsx
import { getPostBySlug } from '@/lib/cms'
import { notFound } from 'next/navigation'

export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map((post) => ({ slug: post.slug }))
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPostBySlug(params.slug)
  if (!post) notFound()

  return (
    <article className="prose prose-lg mx-auto max-w-3xl">
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  )
}

這是默認的服務器組件——不需要 'use client'。CMS 數據在構建時獲取(使用 ISR 進行更新),為你提供快速頁面加載和新鮮內容。

質量保證和設計對比

這是我對每個 Figma 轉 Next.js 項目的質量保證檢查表:

  1. 視覺覆蓋層對比 ——使用 PixelSnap 之類的工具或瀏覽器擴展「PerfectPixel」將 Figma 導出覆蓋在你的構建頁面上。我的目標是 95%+ 匹配,而不是像素完美。在所有瀏覽器和屏幕尺寸上實現絕對像素完美是一個神話。

  2. Lighthouse 審計 ——目標是所有四個分數都達到 90 以上。對於我們的項目,我們通常在性能上達到 95 以上,可訪問性 100,最佳實踐 100,SEO 100。

  3. 跨瀏覽器測試 ——Chrome、Firefox、Safari(特別是 Safari——它總是 Safari)。在實際 iOS 設備上測試,而不僅僅是 Chrome DevTools 移動模擬。

  4. 鍵盤導航 ——通過每個交互元素進行製表。焦點環應該可見且符合邏輯。

  5. 內容壓力測試 ——當標題長度是佔位符的 3 倍時會發生什麼?當圖像的寬高比不同時?真實 CMS 內容將破壞僅適用於完美 lorem ipsum 的設計。

性能優化

一個漂亮的設計,在 Lighthouse 上的分數為 40 是失敗。以下是我在每個項目上做的事情:

  • 延遲加載折下圖像(Next.js 默認執行此操作)
  • 預加載關鍵字體 使用 next/font
  • 最小化客戶端組件 ——每個 'use client' 邊界都添加 JavaScript
  • 使用動態導入 對於重型組件:const Chart = dynamic(() => import('./Chart'), { ssr: false })
  • 優化第三方腳本 使用 next/scriptstrategy="lazyOnload"

從 Figma 設計構建良好的 Next.js 網站應該在 Lighthouse 上得分 90+ 而無需英雄式的優化工作。如果你的分數較低,你可能有太多客戶端組件或未優化的圖像。

如果你正在尋求 Figma 轉 Next.js 項目的幫助並想要這樣的結果,請查看我們的 價格直接聯繫

常見問題

將 Figma 設計轉換為 Next.js 網站需要多長時間? 它在很大程度上取決於項目的複雜性。一個 5 頁的營銷網站,具有清潔設計系統,通常需要 2-4 週的熟練開發人員。一個複雜的 Web 應用程序,具有數十個唯一的組件、自定義動畫和 CMS 集成,可能需要 6-12 週。Figma 檔案質量很重要——組織良好、具有一致組件的檔案可以將開發時間縮短 30-50%。

AI 工具可以完全自動化 Figma 轉 Next.js 轉換嗎? 還沒有。截至 2025 年中旬,Builder.io 的 Fusion、Kombai 和 Locofy.ai 等工具可以生成有用的起點,但沒有一個在沒有重大人工干預的情況下生成生產就緒的代碼。它們最好用作加速器——生成初始 60-70% 的標記——而開發人員處理架構、優化、可訪問性和 CMS 集成。

我應該對 Figma 轉代碼項目使用 Tailwind CSS 還是 CSS Modules? Tailwind CSS 更適合大多數 Figma 轉代碼項目。Figma 設計表示為具體值(顏色、像素間距、字體大小),Tailwind 的效用類直接映射到這些值。CSS Modules 工作得很好,但添加了一個抽象層,減慢了轉換過程。唯一的例外是:如果你的團隊已經有一個成熟的 CSS Modules 代碼庫,保持一致性可能超過轉換速度優勢。

在 Next.js 中處理 Figma 設計令牌的最佳方式是什麼? 使用 Figma 變數(或 Tokens Studio 插件)以結構化格式導出令牌,然後將其轉換為你樣式系統的配置。對於 Tailwind,這意味著擴展 tailwind.config.ts。對於 CSS 自定義屬性,生成 tokens.css 檔案。Amazon 的 Style Dictionary 工具非常適合在格式之間轉換令牌。保持管道自動化,使設計令牌更改在沒有手動工作的情況下傳播到代碼。

當 Figma 檔案只有桌面模型時,我如何處理響應式設計? 這很常見。首先,與設計師交談並建立響應式行為期望。然後實施移動優先,根據你對設計意圖的理解做出布局決策。使用 CSS Grid 和 Flexbox 創建自然響應的布局。如果你不確定,將其存根並在實時構建上獲取設計師反饋——在真實響應式實施上迭代比回到設計更多靜態框架要快得多。

我需要 Figma 的付費計劃才能進行適當的 Figma 轉代碼開發嗎? 免費計劃適用於基本檢查,但 Figma 的開發者模式(自 2025 年起在付費計劃中提供,每座位每月 25 美元)提供顯著更好的開發交接功能:CSS 代碼片段、組件屬性檢查、精確測量和資源導出。對於專業項目,它值得成本。你的替代方案是使用免費的 Figma to Code 插件或 Locofy.ai 等外部工具。

我應該針對 Figma 轉 Next.js 構建瞄準什麼 Lighthouse 分數? 目標是所有類別(性能、可訪問性、最佳實踐、SEO)都達到 90 以上。Next.js 為你提供了強大的起點,但你可以輕鬆用未優化的圖像、太多客戶端組件或繁重的第三方腳本來摧毀你的性能分數。對於我們在 Social Animal 的項目,我們通過保持客戶端組件邊界最少和對所有光柵圖形使用 next/image 來實現 95+ 的性能分數。

我如何隨著時間的推移保持 Figma 設計和 Next.js 代碼庫同步? 這是持續的挑戰。使用設計令牌作為單一的事實來源——當 Figma 中的顏色、排版或間距改變時,更新令牌並重新生成你的 Tailwind 配置。對於組件級更改,建立一個流程:設計師更新 Figma 組件,記錄更改內容,開發人員更新相應的 React 組件。Storybook 之類的工具可以通過提供設計人員和開發人員都可以對照 Figma 源檢查的視覺參考來幫助。