結論先講
一個「能動」的前端專案跟一個「好的」前端專案差距有多大？大概就是你一個人寫 side project 跟一個五人團隊維護三年的差距。好的前端專案不只是畫面漂亮、功能正常，它還需要在型別安全、元件一致性、效能、可及性、測試覆蓋、部署流程上都有基本的保障。
這篇文章就是一張體檢表。拿去對照你手上的專案，看看哪些做到了、哪些還缺。不用一次全補齊，但至少知道差距在哪。
體檢清單
1. TypeScript
如果你 2026 年還在用純 JavaScript 寫正式專案，我真的會幫你默哀。TypeScript 帶來的好處太多了：
- 編譯期就能抓出一堆 bug
- IDE 自動補全和重構超好用
- 程式碼即文件，型別就是最好的說明
// 不好：any 到處飛
function fetchUser(id: any): any {
return api.get(`/users/${id}`);
}
// 好：型別明確
interface User {
id: string;
name: string;
email: string;
role: 'admin' | 'editor' | 'viewer';
}
async function fetchUser(id: string): Promise<User> {
const response = await api.get<User>(`/users/${id}`);
return response.data;
}檢查項目：
- 使用 TypeScript（
strict: true） - 幾乎沒有
any型別 - API 回應有對應的 interface/type
2. 元件庫 / Design System
不是說一定要用 MUI 或 Ant Design，但你的專案需要有一套一致的元件規範。
- 有統一的 Button、Input、Modal 等基礎元件
- 色彩、間距、字型有定義（Design Tokens）
- 有 Storybook 或類似的元件展示工具
3. 響應式設計（Responsive Design）
- 支援手機、平板、桌機三種斷點
- 使用 CSS Grid / Flexbox，不是 float hack
- 有實際在不同裝置上測試過
4. 效能預算（Performance Budget）
{
"budgets": [
{ "type": "initial", "maximumWarning": "500kb", "maximumError": "1mb" },
{ "type": "anyScript", "maximumWarning": "150kb" }
]
}- 設定 Lighthouse 效能分數門檻（至少 80）
- First Contentful Paint < 1.5s
- Bundle size 有上限且 CI 會檢查
- 圖片有做最佳化（WebP/AVIF、lazy loading）
5. Error Boundaries
React 有 Error Boundary，Vue 有 errorCaptured。重點是你的應用不該因為一個元件爆掉就整頁白屏。
// React Error Boundary 基本版
class ErrorBoundary extends React.Component<Props, State> {
static getDerivedStateFromError(error: Error) {
return { hasError: true, error };
}
componentDidCatch(error: Error, info: React.ErrorInfo) {
errorReportingService.log(error, info);
}
render() {
if (this.state.hasError) {
return <FallbackUI error={this.state.error} />;
}
return this.props.children;
}
}- 全域 Error Boundary
- 關鍵區塊有獨立 Error Boundary
- 錯誤有回報到監控系統（Sentry 等）
6. 國際化（i18n / l10n）
即使你現在只做中文，架構先做好未來才好擴充。
- 文字不寫死在元件裡
- 使用 i18n 框架（react-intl、vue-i18n 等）
- 日期、數字格式化有考慮 locale
7. 無障礙（Accessibility）
- 語意化 HTML（
button不是div onClick） - 圖片有 alt text
- 鍵盤可操作
- 色彩對比度符合 WCAG AA
8. SEO Meta
- 每頁有獨立的 title 和 description
- Open Graph / Twitter Card meta tags
- Sitemap 和 robots.txt
- 結構化資料（JSON-LD）
9. Analytics 追蹤
- 頁面瀏覽追蹤
- 關鍵事件追蹤（註冊、購買等）
- 錯誤追蹤（與 Error Boundary 整合）
10. 測試（Unit + Visual）
- 單元測試覆蓋率 > 70%
- 元件有 snapshot 或 visual regression 測試
- E2E 測試涵蓋核心流程（Playwright / Cypress）
11. CI/CD
- Push 就跑 lint + test + build
- PR 有預覽環境（Preview Deployment）
- 主分支合併自動部署
12. Bundle 分析
- 有 bundle analyzer 工具（webpack-bundle-analyzer 等）
- 定期檢查 tree-shaking 效果
- 沒有重複引入相同套件的不同版本
13. 環境設定
- 環境變數管理（
.env.development、.env.production） - 沒有把 API key 寫在程式碼裡
- 有
.env.example說明需要哪些變數
14. 文件
- README 有寫且有用
- 元件有 JSDoc 或 Storybook 文件
- 架構決策有記錄（ADR）
比較表：常見前端框架的預設支援度
| 功能 | Next.js | Nuxt 3 | SvelteKit | Remix |
|---|---|---|---|---|
| TypeScript | 內建 | 內建 | 內建 | 內建 |
| SSR/SSG | 兩者都有 | 兩者都有 | 兩者都有 | SSR 為主 |
| 路由 | 檔案系統 | 檔案系統 | 檔案系統 | 檔案系統 |
| Image 最佳化 | next/image | nuxt-image | 需套件 | 需套件 |
| SEO | next/head | useHead | svelte:head | meta export |
| i18n | 需套件 | @nuxtjs/i18n | 需套件 | 需套件 |
| 測試 | 需設定 | @nuxt/test-utils | vitest 整合 | 需設定 |
| 效能預算 | 需設定 | 需設定 | 需設定 | 需設定 |
實戰範例：一個合格的 package.json scripts 區塊
{
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start",
"lint": "eslint . --ext .ts,.tsx",
"lint:fix": "eslint . --ext .ts,.tsx --fix",
"format": "prettier --write .",
"type-check": "tsc --noEmit",
"test": "vitest",
"test:coverage": "vitest --coverage",
"test:e2e": "playwright test",
"analyze": "ANALYZE=true next build",
"storybook": "storybook dev -p 6006",
"prepare": "husky install"
}
}FAQ
Q1: 小專案也需要這些嗎？
不用全部。但 TypeScript、基本測試、CI/CD 這三個是最低標準。即使是 side project，養成好習慣以後進大團隊才不會痛苦。
Q2: Design System 一定要自己做嗎？
不一定。用 Shadcn/ui、Radix、Headless UI 這類無樣式元件庫，再加上你自己的 Design Tokens，是一個很好的平衡點。
Q3: Lighthouse 分數一定要 100 嗎？
不用。80 以上就算合格，90 以上是優秀。追求 100 分的 ROI 通常不好，把時間花在使用者真正在意的地方比較值得。
Q4: 效能預算怎麼訂？
看你的目標用戶。如果是面向東南亞市場、手機用戶多，bundle size 就要壓更小。一般來說，首次載入的 JavaScript 壓在 300KB 以下（gzipped）是個合理的目標。
Q5: 測試覆蓋率要多高才夠？
70% 是個務實的目標。與其追求數字，不如確保核心商業邏輯和共用元件有測到。100% 覆蓋率不代表沒有 bug。
系列導航
| # | 文章 | 狀態 |
|---|---|---|
| 01 | 好的前端專案該有什麼？一張體檢表 | 📍 你在這裡 |
| 02 | 好的後端框架需要具備哪些功能？ | |
| 03 | 好的 API 該長什麼樣？ | |
| 04 | 好的資料庫設計需要什麼？ | |
| 05 | 好的基礎建設需要什麼？ | |
| 06 | CD Pipeline 需要什麼？ | |
| 07 | 好的監控系統需要什麼？ | |
| 08 | 好的開發者體驗（DX）需要什麼？ |