=================================

大家好 👋，我是 Moment，目前正在使用 Next.js、NestJS、LangChain 開發 DocFlow。這是一個面向 AI 場景的協同文件平台，整合了基於 Tiptap 的富文本編輯、NestJS 後端服務、即時協作與智慧化工作流等核心模組。

在這個專案的持續打磨過程中，我累積了不少實戰經驗，不只是 Tiptap 的深度客製、編輯器效能優化和協同方案設計，也包括前端工程化建設、React 原始碼理解以及複雜專案架構實務。

如果你對 AI 全端開發、文件編輯器、前端工程化或者 React 原始碼相關內容有興趣，歡迎加我的微信 yunmz777 一起交流。覺得專案不錯的話，也歡迎給 DocFlow 點個 star ⭐

企業級前端工程化的本質，是把「人工重複、靠經驗兜底」的開發方式，收斂成可重用、可度量、可演進的一套體系。從零搭建前端時，先想清楚要解決什麼、要什麼結果，再選工具和流程，會少走很多彎路。

工程化主要針對三類問題：

把這三塊從「人治」變成「機制」，工程化才算真正落地。

落到團隊層面，能帶來幾件事。流程上，標準化、能自動化的盡量自動化，關鍵環節可以借 AI 提效；結果上，開發成本下降、迭代速度上來，程式碼品質和可維護性提高，bug 與線上風險更容易被提前攔住。這些都不是單點工具能完成的，需要從需求到上線的整條鏈路一起設計。

接下來我們按常見階段展開，依次是需求與規範、開發與聯調、測試與優化、構建與部署、運維與監控。每個階段會寫目標、推薦流程、常用工具、典型場景，以及適合用 AI 或自動化做得更好的地方。

前端工程化總覽

整條鏈路可以概括為五個階段，從需求規範到運維監控依次串連。整體追求三個結果：穩（高可用、可回滾）、快（敏捷交付、自動化流水線）、省（低成本工具鏈、資源重用），下面用一張流程圖把階段關係畫清楚。

各階段側重不同。需求規範階段重在建立統一標準、預防潛在風險、提升協作效率，常見動作包括需求與介面規範、文件沉澱與知識庫、以及用 AI 做文件自動化。開發聯調階段和測試優化階段共同指向高效協作、減少阻塞、保障程式碼品質，前者涵蓋基礎框架與腳手架、元件與物料庫管理、工程化工具鏈、前後端介面聯調與 Mock，後者涵蓋單元與 E2E 自動化測試、效能與體積優化、合規與安全掃描、埋點與資料上報。構建部署階段和運維監控階段則共同強調高效交付、穩定發佈、靈活回滾，構建部署側重構建與打包優化、CI/CD 部署方案、灰度發佈與一鍵回滾，運維監控側重效能與可用性監控、異常與錯誤追蹤、使用者行為與轉化分析、大螢幕可視化與告警，目標是即時感知風險、快速定位原因、持續優化體驗。

下圖是同一套階段與目標的示意，便於對照查閱。

需求規範階段

需求規範階段是整條鏈路的起點。先把這一步打牢，後面的開發聯調、測試優化才不會一路踩坑。這裡要做的事，本質上是把團隊裡各自為戰的習慣和經驗，沉澱成一套大家都認可的統一標準，既預防潛在風險，又減少日常協作裡的摩擦。為了方便梳理，可以把這一階段拆成三塊，對應程式碼與介面、文件與知識庫，以及用 AI 做文件自動化。

下圖是這一階段的手繪示意，可以當作後文三小節的導航來對照著看。

需求與介面規範

落到開發這側，最直觀的感受就是，大家寫出來的程式碼和提交流程要像是一個團隊，而不是各寫各的。第一步是把程式碼規範和協作流程統一，用一套約定來消除協作摩擦。程式碼這一塊，可以用 ESLint、Prettier 搭配 Husky 去強制約束程式碼風格，縮排、命名這些細節交給工具，提交前自動跑一遍，不通過就推不上去，討論就能更多回到設計和實作本身。

協作流程方面，建議一開始就說清楚 Git 分支策略（例如簡化版 Git Flow）和 Commit 訊息格式，例如用 Commitizen 這樣的工具來規範提交說明。久而久之，提交歷史會變成一本可以查帳的專案日記，誰在什麼時間、因為什麼調整了哪些程式碼，一目了然。

這裡有兩類問題，最好在一開始就透過規範擋住。一類是隨手寫 fix bug、update 這類沒資訊量的提交訊息，事後誰也看不出當時改動的動機。另一類是沒經過 Code Review 就把改動直接合進主分支，品質風險一路帶到線上。有些團隊會要求，所有人都基於 master 拉分支開發，在 test、uat、release 這些共用環境分支以及 master 上都禁止直接 push，只能透過合併請求（Merge Request / Pull Request）進入，這樣一旦出問題，也能順著合併記錄快速定位到具體改動。

文件沉澱與知識庫

文件沉澱這塊，目標是打破資訊孤島，讓新人靠看文件也能盡量還原當時的需求背景和取捨過程。需求如果只散落在聊天記錄裡，過一陣子連原作者自己都很難說清楚當時為什麼要這麼定。比較實用的做法，是用語雀、飛書文件把業務需求拆成技術方案，把功能邊界和驗收標準寫清楚，再準備一套固定的需求文件範本，背景、原型、介面定義這些模組都預留好位置，後面類似需求直接套用，既省事又不容易漏。

介面和設計的配合，同樣可以透過工具來固化。可以用 Apifox 維護介面文件，後端介面還沒完全就緒時，前端先基於 Mock 資料開發，不必空等。與此同時，聯動 Figma、即時設計這類工具裡的設計稿標註，讓 API 與設計稿保持同步，很多原本要靠口頭解釋的細節，直接在文件和設計稿裡就能對齊。

AI 賦能文件自動化

如果完全手寫，一份中等複雜度的技術文件，往往要花上兩到四個小時，寫著寫著還容易走神。現在可以把這種重複性工作交給 AI。例如用 Writely（飛書 AI），輸入 PRD 裡的關鍵字（例如「使用者管理系統」），讓它先生成一份大致合理的技術文件目錄和範例程式碼片段，你再依實際業務補充細節、刪掉不適用的部分。

實際體驗下來，傳統純手寫從零到一可能要兩到四個小時，而讓 AI 先搭好骨架、再人工完善，大多數情況下半小時左右就能收工。這樣的方式尤其適合需求說明、介面說明、技術方案骨架這類重複度很高的文件，一方面整體結構更統一，另一方面也把時間留給那些必須由人來判斷的業務決策和權衡。

開發聯調階段

開發聯調階段是前端工程化真正動手寫程式碼、跑起來的那一段，目標很清晰，就是高效協作、減少阻塞、保障程式碼品質，讓前後端和設計之間盡量無縫銜接。下面按基礎框架、物料復用、工程化流水線、前後端協作四塊來說，最後補幾條聯調時容易踩的坑。

基礎框架搭建

框架選型決定了團隊未來幾年的技術底座，選好了能少踩很多坑。輕量一點、迭代快的專案，可以用 Vue 3 或 React 搭配 Vite，開發體驗好、上手也快，Vite 後續會整合 Rust 實作的 Rolldown，生產構建會更快。業務比較複雜、偏中後台或需要 SSR 的，可以看 Next.js、Rsbuild 等，Next.js 開發環境已支援 Turbopack，大倉冷啟和 HMR 更猛。超大體量或需要相容既有 Webpack 生態的，可以看 Rust 系的 Rspack。執行時除了 Node.js，也可按需選 Bun 做腳本和工具鏈。要是還有小程式、H5 等多端需求，可以看 Taro、Uni-App 這類跨端方案，一套程式碼多端跑。

選完框架，最好再準備一套範本倉庫，新專案直接基於範本拉，而不是每次從零配置。例如預置好 ESLint、Prettier 的腳手架，或者用 Next.js、Rsbuild 等自帶的腳手架快速生成專案，再按需加權限、資料流等。如果團隊裡會有多個應用、共用元件庫或公共套件需要一起維護，可以提前考慮是否採用 Monorepo 架構（例如用 pnpm workspace、Turborepo、Nx 等），把多包放在一個倉庫裡統一依賴和構建，能減少後期拆倉、版本對齊的折騰。這一步也可以交給 AI 省時間，例如在 Cursor 裡輸入「建立 NextJs + TypeScript 專案」，讓它生成基礎配置。

物料庫管理

元件、工具函數、頁面範本如果能重用，重複開發會少很多。有條件的團隊會做企業自研元件庫，常見兩條路。一條是在 Ant Design、Element Plus 這類開源元件庫上做二次封裝，貼合自家業務和設計規範，再用 Bit 這類工具管理元件版本和依賴，甚至支援私有化部署。

另一條是，如果團隊已經在用 Tailwind CSS，並且用過 shadcn/ui 這類「複製即用」的元件方案，可以在現有基礎上做二次開發，例如統一品牌色、間距和圓角等 design token，把常用變體收攏成團隊約定，再補一份內部文件（哪些元件可直接用、哪些改過、使用範例和注意事項），這樣既保留 Tailwind 的彈性，又有一致的設計和可維護的物料沉澱。Tailwind CSS v4 已發布，構建更快、配置更簡單，新專案可以直接上 v4。工具函數這塊，用 lodash、dayjs 等成熟套件即可，不必自己造。

AI 在這塊也能幫上忙。例如即時 AI 可以把 Figma 設計稿轉成 Vue、React 元件程式碼，減少從設計到程式碼的重複工作。CodeGeeX 可以根據元件的 Props 描述自動生成單元測試用例。當然，小團隊或小公司不一定要自建元件庫和物料體系，先把業務跑穩、再按需沉澱元件和範本，會更務實。

工程化系統

工程化系統說白了就是透過工具鏈把建立專案、檢查、構建、部署串成一條流水線，減少人工操作。建立專案階段，現在普遍用 Vite 建立 Vue、React 專案（create-vite 或各框架官方範本），或用 Next.js 自帶的腳手架起手，預置好規範與配置即可。到了持續整合與部署，可以用 GitHub Actions、GitLab CI 在提交後自動跑程式碼檢查、構建和部署，或者用 Jenkins 做更複雜的多環境流水線。如果希望需求、開發、部署都在一個平台裡完成，可以選阿里雲效這類一站式 DevOps 平台，功能全、上手相對簡單，也支援私有化部署，不少團隊的實際專案就是用雲效搭的流水線。

前後端協作

前後端聯調最容易出問題的地方，往往是介面約定不一致、文件滯後、環境對不齊。介面文件建議用 Apifox、Apidog 這類工具維護，支援 OpenAPI 規範、自動 Mock 和介面測試。許多平台還能根據介面文件自動產生前端的請求程式碼和 TypeScript 類型，文件一改、類型跟著變，減少手寫介面定義。後端介面還沒好時，前端可以先用 Mock.js、Faker.js 產生貼近真實的測試資料，或者用 MSW（Mock Service Worker）在瀏覽器層做請求攔截，搭配 TypeScript 做類型安全的 Mock，適合單測和本地聯調。全端都是 TypeScript 的專案，還可以考慮 tRPC 或更輕量的 Hono RPC，前後端共享類型定義，服務端改介面、客戶端立刻有類型提示，無需單獨維護一份介面文件和類型。Hono RPC 用 hc 客戶端加 Zod 驗證即可實現類型安全，適合前後端同倉或協作緊密的團隊。

當介面多了、前端需要彙整多個介面或按需拉欄位時，可以加一層 BFF（Backend For Frontend），用 Node.js 中間層（例如 NestJS、Midway.js、Express）彙整多介面，或者用 GraphQL（如 Apollo Server）讓前端按需定制回應欄位。BFF 可以由後端團隊維護，也可以由前端團隊自建，實現真正的介面層解耦。

介面文件若能透過統一協定進到開發環境裡，前後端對接會輕鬆很多。可以把後端的 OpenAPI 規範用 MCP（Model Context Protocol）暴露出來，例如用 OpenAPI MCP Server 把介面定義轉成 MCP 的 tools、resources，在 Cursor、VS Code 等 IDE 裡配置好 MCP 後，就能在寫程式碼時直接讀到最新介面文件、讓 AI 按文件生成請求程式碼或類型，避免文件和實作脫節。

阿里雲、騰訊雲等也有 OpenAPI MCP Server，適合把雲產品 API 接到 IDE。自建後端可以用 @reapi/mcp-openapi、FastMCP 的 from_openapi() 等從 OpenAPI 規範生成 MCP 服務，前後端共用同一份文件，聯調時介面變更能更快同步到前端。

AI 也能參與進來，例如 Apifox 的 AI 可以根據介面文件自動生成 Mock 規則和測試用例，CodeGeeX 可以根據現有 RESTful 介面生成一層 GraphQL 包裝程式碼，減少手寫膠水程式碼。

聯調時還有幾點值得注意。一是介面變更要即時同步，用 Apifox 這類工具把最新介面定義推給前端，或透過 OpenAPI 自動生成類型，避免文件和實作各說各的。二是開發、測試、生產環境要隔離，用 .env.development、.env.production 等把配置拆開，別在本地寫死生產地址。三是相依版本要鎖死，用 pnpm 等套件管理器嚴格鎖定相依，能少很多「在我機器上沒問題」這類問題。

測試優化階段

測試優化階段的目標很明確，就是提前暴露風險、保障線上穩定、提升使用者體驗，用分層測試把核心場景兜住，減少漏測和線上事故。從人工點點點到自動化、再配合 AI 生成用例，測試效率會明顯上去。

自動化測試

建議按單元測試、E2E、視覺回歸三層建體系，而不是一上來就全押 E2E。單元測試負責驗證元件邏輯和工具函數，用 Jest 或 Vitest 配 React Testing Library 即可，Vitest 與 Vite 同源、冷啟和 HMR 更快，適合在每次提交時跑。元件層若要在真實瀏覽器裡跑，可用 Vitest 的 Browser Mode 配 Playwright 驅動。例如下面這段，用 render 渲染按鈕元件、screen.getByRole 找到按鈕並模擬點擊，再斷言傳入的 onClick 被呼叫了一次，用來保證點擊回呼不會遺失。

<div><div><div></div><span>typescript</span></div><div><div> <span>體驗AI程式碼助手</span></div><div> <span>程式碼解讀</span></div><div>複製程式碼</div></div></div>```
<span><span>test</span>(<span>"Button 點擊觸發事件"</span>, <span>async</span> () => {</span>
<span>  <span>const</span> handleClick = vi.<span>fn</span>void</span>>();
<span>  <span>render</span>(<span><span>MyButton</span> <span>onClick</span>=<span>{handleClick}</span> /></span></span>);
<span>  <span>await</span> userEvent.<span>click</span>(screen.<span>getByRole</span>(<span>"button"</span>));</span>
<span>  <span>expect</span>(handleClick).<span>toHaveBeenCalledTimes</span>(<span>1</span>);</span>
<span>});</span>

E2E 測試覆蓋真實使用者流程，在瀏覽器裡跑完整流程。`Playwright` 支援 Chromium、WebKit、Firefox 多端，自帶錄製回放，適合做跨瀏覽器回歸。`Cypress` 的可視化除錯和時間旅行對複雜互動（例如購物車、多步表單）很友善，按團隊習慣二選一或搭配使用即可。

視覺回歸測試解決的是「功能沒壞、但介面悄悄變了」的問題。改了一處樣式或相依升級導致元件渲染異常，單測和 E2E 不一定能發現，視覺回歸透過對比頁面或元件的螢幕截圖，先拍一份基準快照，後續每次跑用例時再拍一張，和基準做像素或區域對比，有差異就彈出來，由人工確認是預期改動還是誤傷。可以用 `BackstopJS` 在本地或 `CI` 裡跑，配置好要截的 URL 或元件，生成基準後納入版本管理，以後每次 `PR` 自動跑一遍對比。元件庫或設計系統也可以用 `Chromatic`、`Percy` 這類託管服務，和 `Storybook` 結合，每個 Story 自動做視覺回歸。適合對 UI 穩定性要求高的首頁、關鍵流程頁和公共元件，基準圖多了之後要注意維護，避免無關改動帶來大量噪音。

`AI` 也能參與測試用例的生成和驗證。一類是依據行為資料生成腳本，例如 Testin `AI` 分析使用者行為日誌，把高頻操作轉成 E2E 用例，先覆蓋核心路徑再補邊緣場景。另一類是讓 `AI` 直接連上真實瀏覽器做除錯和驗證，例如 Chrome 官方的 Chrome DevTools MCP，在 Cursor、Claude 等裡配置好 MCP 後，`AI` 可以調用 `DevTools` 能力做效能追蹤、網路與 Console 排查、DOM 與樣式檢查、表單與使用者行為模擬，並在瀏覽器裡即時驗證改動的效果，相當於「邊寫程式邊在真機裡跑一遍」。和 Playwright MCP 搭配時，Playwright 負責 UI 自動化與用例執行，DevTools MCP 補足效能與執行時觀測，適合做智慧回歸和 Core Web Vitals 等自動化檢查。

### 效能優化

測試通過之後，還要保證頁面秒開、互動不卡。可以給自己訂一個簡單目標，例如首屏可互動 FCP 控制在 1.5 秒內、首次輸入延遲 FID 在 100ms 以內。效能檢測方面，用 Lighthouse CI 把跑分整合進 `CI` 流水線，分數低於閾值（例如 90）就擋掉合併，避免效能退化程式碼進主幹。真實使用者資料用 Google Analytics 4 或阿里雲 ARMS 采集 Web Vitals，看線上實際表現而不是只看本機。

優化手段按資源、程式碼、傳遞來拆。資源上，構建階段自動壓縮圖片，例如用 `vite-plugin-imagemin` 在打包時處理；程式碼上，用 `React.lazy` 配 `Suspense` 做路由級懶載入，首屏只拉當前路由需要的 `chunk`。傳遞上，靜態資源丟到阿里雲 OSS 再掛 CDN，利用全球節點做加速。`AI` 也能參與，例如阿里雲 ARMS 的智慧診斷會根據效能資料推薦優化項（如未壓縮圖片列表），部分構建工具已支援基於預測的 Tree Shaking 策略，進一步剔除無效程式碼。

### 合規與安全

合規與安全要從程式碼和資料兩頭抓，避免法律風險和使用者隱私問題。程式碼端，用 SonarQube 做靜態掃描，揪出 XSS、SQL 注入等常見漏洞。相依端，用阿里雲安全中心等掃描已知漏洞（例如 Log4j、老舊版本的 `lodash`），有風險就升級或替換。隱私合規方面，用騰訊雲合規助手這類工具檢查隱私政策是否符合 GDPR、個資法等要求。日誌裡對手機號碼、身分證號等做脫敏，例如透過 `log4js` 等外掛的過濾規則自動打碼，避免敏感資料落盤。

`AI` 可以輔助安全掃描，例如用大模型掃描程式碼裡的敏感資訊（如硬編碼的 API 金鑰）。部分 `AI` 程式碼助手能自動把不安全寫法替換成更安全的實作（如將 `eval` 改為 `Function`），適合在 Code Review 前跑一遍。

### 資料埋點

埋點做得好，產品迭代才有資料支撐，否則容易變成「盲人摸象」。埋點大致分無埋點和自訂埋點。若注重隱私或希望資料自托管，可以用 `Umami` 這類開源方案，無 Cookie、符合 GDPR、腳本輕量（約 2KB），支援頁面瀏覽與自訂事件，可 Docker 自建或使用官方雲，適合中小站點和不想依賴第三方統計的場景。

無埋點還可用 GrowingIO 等方案自動採集頁面點擊、曝光等事件，接入簡單、覆蓋面大。自訂埋點用神策數據等 SDK 在關鍵行為（如按鈕點擊、表單送出）上手動上報，靈活、可針對業務做分析。資料進來之後，用 Metabase 這類開源 BI 做 SQL 自助分析，或用阿里 DataV 做大螢幕展示核心指標（如 DAU、轉化率）。`AI` 也能參與，例如 GrowingIO 的智慧推薦會根據使用者路徑建議高價值埋點事件，神策的聚類分析能自動識別使用者分群（如高流失風險使用者），方便做精細化經營。

測試與優化階段還有幾點容易踩坑。一是別盲目追求 100% 測試覆蓋率，優先把核心鏈路（登入、支付等）兜住，再按需補邊緣場景。二是效能優化別撒胡椒面，內部管理後台等低頻頁面不必死磕，把資源留給使用者高頻訪問的頁面。三是埋點必須取得使用者授權，禁止收集裝置 ID、IMEI 等敏感資訊，否則會踩到資料隱私的地雷。

構建部署階段
------

構建與部署階段是前端工程化的交付出口，目標是高效交付、穩定發佈、靈活回滾，讓程式碼從開發環境到生產環境順暢流轉。下面按構建優化、部署方案、灰度與回滾三塊說。

![20260226094131](https://i.imgur.com/S4I09zq.jpeg)

### 構建優化

構建工具在技術選型階段通常已經定好了（例如 `Vite`、`Webpack 5`、`Rspack`、`Next.js`），這裡側重在既定工具上的優化策略。`Vite` 新版本已接入 Rust 實作的 Rolldown 做生產打包，構建耗時明顯下降。選 `Next.js` 的可以用 Turbopack 做開發和生產構建，冷啟和增量構建更快。`Rspack` 等 Rust 系方案在大倉下同樣有優勢。

優化時先把 Tree Shaking 開滿，在函式庫和業務裡合理配置 `sideEffects: false`，讓打包器刪掉未引用程式碼。程式碼拆分用動態 `import`、`React.lazy` 把非首屏做成按需載入，再用 `manualChunks` 把大相依（如 `monaco-editor`、圖表庫）單獨拆包，避免首屏 `chunk` 過大。產物體積可用 `rollup-plugin-visualizer` 或 `vite-plugin-perfsee` 做分析，一眼看出誰在占空間。線上傳輸用 `vite-plugin-compression` 做 Gzip 或 Brotli，Nginx 端開 `gzip_static` 即可。

部分構建工具已支援基於 `AI` 的智慧快取和構建日誌分析，自動建議合併重複 Chunk、優化相依順序等，可在 `CI` 裡跑一遍看報告。

### 部署方案

部署從手動發包走向一鍵發佈、多環境隔離，才能做到分鐘級回滾。靜態資源托管最常見，用阿里雲 OSS 掛 CDN 按量付費、支援快取刷新，或選託管平台：Vercel 和 `Git` 深度整合、推分支即發佈，適合 `Next.js`。Cloudflare Pages 邊緣節點多、免費頻寬大，已支援 Docker 和 `@opennextjs/cloudflare` 跑 Next，還有 Workers AI 做邊緣推理。Netlify 在組合式架構和 CMS 整合上比較順手。需要極快 git 部署、少建站過程的可以看 Deno Deploy，程式碼直傳邊緣、無需拉機子做長構建，適合接口或中間層。

需要跑 `Node` 或做 SSR 的，用 Docker 多階段構建把映像壓到幾十 MB，再配合 Kubernetes（如阿里雲 ACK）做叢集。不想管機器的用 Serverless，阿里雲函數計算、Vercel Edge Functions 等按需執行、邊緣就近跑。

`AI` 也能參與，例如 GitLab Code Suggestions 可根據專案生成 `Dockerfile` 或 `CI` 腳本，觀測雲等能根據資源負載推薦擴縮容策略。

### 灰度與回滾

發佈要可控，灰度把風險壓到最小，回滾要能快速切回去。灰度本質是流量逐步切到新版本，常見做法有 Nginx 按 IP 或 Cookie 分流，先給 5%～10% 使用者上新版，觀察一段時間再放量。阿里雲 EDAS 支援全鏈路灰度，應用和資料庫都能隔離。雲原生 API Gateway 也支援藍綠、金絲雀發佈，按比例或規則切流量。除了流量灰度，還可以用功能開關（Feature Flags），在程式碼裡用開關控制功能是否露出，用 ConfigCat、LaunchDarkly 等或自研，發版和上線解耦，隨時可關。

灰度期間要有可觀測，接 Prometheus、Grafana 或既有監控，盯錯誤率、回應時間，一旦超閾值（例如錯誤率 > 0.5%）自動回滾或告警。回滾要提前準備好，在 GitLab CI 或 GitHub Actions 裡做基於版本 Tag 的回滾腳本，出問題一鍵切回上一版。靜態資源用 OSS 版本控制保留歷史，回滾時改 CDN 回源即可。

`AI` 也能參與，例如阿里云 AHAS 可根據歷史流量建議灰度比例，Sentry 等可在錯誤率突增時自動觸發回滾或通知，減少人工判斷時間。

運維監控階段
------

運維與監控是前端工程化的最後一道防線，目標是即時感知風險、快速定位原因、持續優化體驗，讓線上系統穩定、使用者行為可觀測。下面按效能監控、異常監控、使用者行為分析、可視化與告警四塊說，最後補一版低成本與大型企業的工具鏈參考，以及幾條容易踩的坑。

![20260226095212](https://i.imgur.com/89AvRh7.jpeg)

### 效能監控

效能監控要保障 Web Vitals 等核心體驗指標達標，並持續發現瓶頸。核心指標用 Google Analytics 4 或阿里雲 ARMS 等採集真實使用者資料（RUM），關注 LCP（最大內容繪製）、INP（互動到下一幀，已逐步替代 FID）、CLS（累積版面偏移）等，可搭配 `web-vitals` 函式庫在端上採集後上報。除了平台自動採集，關鍵鏈路可以加自訂效能埋點，例如在頁面載入完成後取 `performance.timing` 算出載入耗時並上報，方便按頁面或版本對比。下面範例在 load 事件後計算從導航開始到載入結束的耗時，並透過自有 SDK 上報，用於做首屏效能趨勢分析。

<div><div><div></div><span>typescript</span></div><div><div> <span>體驗AI程式碼助手</span></div><div> <span>程式碼解讀</span></div><div>複製程式碼</div></div></div>```
<span><span>const</span> <span>timing</span>: <span>PerformanceTiming</span> = performance.<span>timing</span>;</span>
<span><span>const</span> <span>loadTime</span>: <span>number</span> = timing.<span>loadEventEnd</span> - timing.<span>navigationStart</span>;</span>
<span><span>SDK</span>.<span>report</span>({ <span>type</span>: <span>"page_load"</span>, <span>duration</span>: loadTime });</span>

資源端可以看 CDN 日誌分析請求成功率、快取命中率（如阿里雲 CDN）。介面耗時用 SkyWalking、Zipkin 或 OpenTelemetry 做鏈路追蹤，約定 P99 等目標（例如 500ms 以內）。Sentry 等已支援與 OpenTelemetry 對接，前端錯誤和介面鏈路可以串成一條 trace，排查時從頁面一路跟到後端。AI 也能參與，例如阿里雲 ARMS 智能診斷會關聯 JS 錯誤與介面超時，給出根因建議。New Relic 等可根據歷史資料預測流量峰值，輔助提前擴容。

異常監控

異常監控要爭取分鐘級發現線上問題，把 MTTR（平均修復時間）壓下去。錯誤追蹤用 Sentry 捕捉前端 JS 錯誤、自動聚合相似問題，並支援 SourceMap 解析還原原始碼位置。國內團隊也可以用支援微信、釘釘即時告警的國產方案，和既有協作習慣對齊。日誌分析用阿里雲 SLS 做 Nginx 訪問日誌的即時分析，快速發現 5xx 突增等異常。自建可選 Loki 配 Grafana，資源佔用比傳統 ELK 小，用 LogQL 查「近 1 小時 404 TOP10」這類問題很順手。

AI 可以輔助降噪和歸因，例如 Sentry 的智慧聚類能把大量錯誤歸成少量根因（如未捕獲的 TypeError）。基於 Elasticsearch Machine Learning 或類似能力可以做日誌模式異常檢測，例如發現突然出現大量非常規 UA 或異常請求路徑，提前察覺爬蟲或攻擊。

使用者行為分析

使用者行為資料用來驅動產品優化和轉化率提升。無埋點用 GrowingIO 等自動採集頁面點擊、跳轉、停留時長，並生成熱力圖。自訂分析用神策數據等做事件與漏斗（如註冊流程各步轉化）。關鍵業務節點需要自訂埋點時，在按鈕或流程節點上打點上報事件和業務參數，例如下單按鈕點擊時上報商品 ID 和價格，便於後續做轉化和營收分析。下面範例在購買按鈕點擊時上報事件名和業務欄位，接入方替換成實際 SDK 即可。

<div><div><div></div><span>typescript</span></div><div><div> <span>體驗AI程式碼助手</span></div><div> <span>程式碼解讀</span></div><div>複製程式碼</div></div></div>```
<span><span>document</span>.<span>getElementById</span>(<span>"buy-button"</span>)?.<span>addEventListener</span>(<span>"click"</span>, <span>() =></span> {</span>
<span>  <span>SDK</span>.<span>track</span>(<span>"purchase_click"</span>, { <span>product_id</span>: <span>"123"</span>, <span>price</span>: <span>299</span> });</span>
<span>});</span>

`AI` 能參與分析結論的產出，例如神策的智慧路徑分析使用者流失點並給出優化建議，GrowingIO 可根據行為聚類生成推薦或營運策略參數。

### 可視化與告警

監控資料要透過大螢幕和告警變成可執行的決策。可視化用 Grafana 做自訂監控面板，或用阿里雲 DataV 搭即時運維大螢幕。告警用 Prometheus 配 Alertmanager 設定閾值（如 CPU 使用率 > 80% 持續 5 分鐘），告警事件透過釘釘、飛書機器人推到協作群，並支援 @ 負責人。`AI` 可以用於智慧閾值和降噪，例如根據歷史資料動態計算合理閾值（如凌晨自動放寬延遲閾值），或把重複告警合併成一條，減少告警風暴。

### 工具鏈參考

中小團隊、預算有限時，可以組合：監控用 Prometheus 自建 + Grafana，告警接微信或釘釘。日誌用 Loki 替代 ELK，資源消耗更低。再搭配阿里雲 ARMS 免費版做基礎效能分析、或開源元件的異常檢測能力，整體月成本可控。對高可用要求高、資料量大的團隊，可以用阿里雲 ARMS 做全鏈路、SLS 做 PB 級日誌，配合 DataV 大螢幕和自研或第三方 `AI` 分析平台。

---

原文出處：https://juejin.cn/post/7619174110456987686