2026 年香港企業必讀：用 Native Web Components 打破 React、Vue、Angular 的設計系統孤島

香港企業的「框架戰國時代」：為何設計系統總是四分五裂

走進任何一間中環金融機構或觀塘的科技團隊，你很可能會看到同一間公司同時維護著三套前端技術棧。核心銀行系統是十多年前的 Angular 遺產，去年新推出的客戶 App 用 React Native 加 React Web，而市場部那個追趕潮流的會員平台則選了 Vue 3。每個團隊都覺得自己的選擇合理，但當品牌部門要求「所有渠道的按鈕、表單、提示訊息都要一致」時，噩夢就開始了。

問題的根源在於：過去十年我們設計的「元件」本質上是框架的產物。一個 React 的 <Button> 是 JSX 加 hooks 的組合，一個 Vue 的 <Button> 是 SFC 加 props 的組合，兩者無法直接互通。於是企業被迫走上三條路：一是每個框架各自重寫一次設計系統；二是用 iframe 或微前端硬塞，換來效能與體驗的妥協；三是選擇其中一個框架「一統天下」，但遷移成本往往高得讓管理層卻步。

2026 年的處境更加微妙。香港企業歷經數位轉型預算緊縮與人才流動，前端團隊規模普遍縮小，卻要支撐更多渠道——網站、App、內部後台、甚至門市的 kiosk。在這種情況下，「一次開發、到處使用」不再只是工程師的浪漫，而是實實在在的成本控制手段。Native Web Components 正是在這個脈絡下重新回到談判桌。

什麼是 Native Web Components？拆解自訂元素、Shadow DOM 與 HTML Templates

Native Web Components 不是新產品，而是瀏覽器原生支援的一組標準，主要由三部分組成。第一是 Custom Elements，讓你用 customElements.define('scg-button', ...) 註冊一個真正的 HTML 標籤，之後在任何框架裡都能像寫 <div> 一樣寫 <scg-button>。第二是 Shadow DOM，它為元件提供樣式與 DOM 的封裝邊界，外面的 CSS 不會意外污染元件內部，元件的樣式也不會外洩。第三是 HTML Templates，透過 <template> 與 <slot> 定義可重用的結構與內容插槽。

這三者加起來，等於把「元件」從框架的私有財產，還原成瀏覽器層級的公共資源。對香港企業而言，這件事的意義在於：設計系統的資產終於可以存在於框架之外。你的品牌按鈕不再是一段 React 程式碼，而是一個瀏覽器看得懂的自訂元素；無論上層是 React、Vue、Angular，甚至是幾年前以為已經死掉的 jQuery 後台，都可以直接呼叫同一個元件。

當然，原生標準並非萬能。它沒有框架提供的響應式狀態管理、沒有內建的路由、也沒有成熟的開發者體驗工具鏈。但這正是它作為「共享層」的優勢：它刻意保持中立與低階，讓每個框架繼續用自己擅長的方式處理應用邏輯，只把最需要統一的 UI 元件下沉到原生層。這種分層思維，是 2026 年香港團隊應該建立的架構共識。

Design System Distribution：把設計代幣與元件庫變成框架中立的資產

設計系統的散佈（distribution）向來是最容易被低估的環節。香港不少企業的設計系統其實做得不錯，問題是它被困在 Figma 與某一個 npm package 裡。當新專案用不同框架時，設計師只能「口頭交代」或重新標註，工程師則憑感覺重寫，久而久之品牌一致性就崩壞。Native Web Components 提供了一條更乾淨的散佈路徑。

第一步是把 design tokens 從框架的 theme provider 中抽離，改成 CSS 自訂屬性（CSS Custom Properties）。例如 --scg-color-primary、--scg-radius-md、--scg-space-4 這些變數定義在根層級，任何框架、任何元件都能讀取。第二步是把元件打包成標準的 ES Module，透過 npm 或企業內部的私有 registry 發佈。使用端只要 import '@scg/ui-components'，瀏覽器就會註冊所有自訂元素，完全不需要框架專屬的 wrapper。

以香港某虛擬銀行的內部後台為例，他們的設計系統原本有 React 與 Angular 兩套版本，每次品牌改色都要改兩個 repo，平均延遲三到四週才全面生效。改用 Web Components 作為單一來源後，設計代幣一改，兩邊後台在同一次部署就同步更新。更關鍵的是，他們的門市 kiosk 用的是較舊的技術棧，過去根本無法納入設計系統，現在也能直接使用同一批元件，真正做到全渠道一致。

Browser Support 實況：2026 年的原生支援還差什麼？

談到原生標準，香港工程主管最常問的一句是：「IE 怎麼辦？」到了 2026 年，這個問題基本可以放下。Custom Elements v1、Shadow DOM v1、HTML Templates 在 Chrome、Edge、Firefox、Safari 的主要版本都已穩定支援多年，包含 iOS 與 Android 上的行動瀏覽器。對於仍在使用較舊 Safari 或企業內部舊版瀏覽器的情況，可以透過極輕量的 polyfill 補足，成本遠低於維護三套框架元件。

真正需要注意的是「不是瀏覽器，而是工具鏈」的相容性。Shadow DOM 的樣式封裝會讓某些全域 CSS reset 失效，這在講究細節的金融品牌設計中需要特別處理，通常透過 ::part() 與 CSS 自訂屬性開放受控的樣式接口。另外，伺服器端渲染（SSR）與宣告式 Shadow DOM（DSD）的支援度逐年成熟，對香港愈來愈重視 SEO 的零售與媒體網站來說，這是必須預先規劃的環節。

還有一個常被忽略的實務點：表單元件的參與。自訂元素要能被 <form> 正確提交，需要實作 ElementInternals 與 formAssociated，這在 2026 年已是主流瀏覽器支援的能力。對香港的公營機構與銀行來說，表單是核心業務流程，這項能力決定了 Web Components 能否進入真正關鍵的場景，而不只是做做行銷頁面的按鈕。

Migration Strategies：香港團隊的漸進式遷移路線圖

遷移策略沒有魔法，只有取捨。對大多數香港企業，我建議採取「由外向內、由共用向核心」的漸進路線。第一階段，先從跨框架重複度最高、業務風險最低的元件下手，例如按鈕、輸入框、標籤、提示訊息與圖示。這些元件在各個專案重複實作，改動頻率高，換成 Web Components 的投資回報最快，也最容易說服管理層。

第二階段，處理跨渠道共用的複合元件，例如會員登入卡、產品價格顯示、訂單狀態時間軸。這些元件牽涉較多業務邏輯與樣式細節，適合用 Web Components 封裝，並透過屬性與事件與外層框架溝通。關鍵原則是「框架負責資料流，元件負責呈現」，避免把狀態管理塞進元件內部，否則又會製造新的耦合。香港某大型零售集團就是用這個方式，讓網站與 App 共用同一套會員元件，改版時只需維護一份。

第三階段才是核心流程的遷移，例如結帳流程或開戶流程。這類場景建議採用「頁面內混合」策略：外層仍由現有框架掌控路由與狀態，逐步把流程中的區塊替換成 Web Components。這樣做的好處是每一步都可回滾，不會出現「大爆炸式重寫」的災難。實務上，香港團隊常見的阻力不是技術，而是內部對「新技術」的信任不足，因此每個階段都應該設定可量測的指標，例如元件重複率下降、品牌改版週期縮短、跨團隊交付時間減少。

香港案例與實務建議：從成本、人才到治理

把視角拉回香港的商業現實。本地企業普遍面對三個約束：IT 預算審批嚴格、資深前端人才流動快、合規與稽核要求高。Native Web Components 在這三點上都有對應價值。成本方面，它減少重複開發與跨框架維護，對照上述虛擬銀行的例子，品牌改版週期從數週縮短到數天，等於直接省下人力。人才方面，自訂元素是標準 HTML 與 JavaScript，新加入的工程師不需要先精通三個框架才能改 UI，降低了上手門檻。

合規方面，Shadow DOM 的封裝特性其實有利於稽核：元件的樣式與行為邊界清楚，第三方追蹤碼或外部 CSS 不易滲透進關鍵 UI，對金管相關的介面一致性要求反而是加分項。當然，企業仍需建立內部治理機制，例如元件的版本策略、破壞性變更的公告流程、以及與設計團隊的 token 同步機制。這些治理工作不會因為用了 Web Components 而消失，反而更需要在「共用層」上認真對待。

最後給香港團隊三個實務建議。第一，先建立一個小而穩的核心元件庫，不要一開始就追求大而全，五到十個高頻元件就能產生可見效益。第二，投資在文件與範例，因為跨框架共享的前提是每個團隊都看得懂怎麼用，Storybook 或類似的展示環境是必要的。第三，把設計代幣與元件分開發佈，讓品牌層的變更能獨立於程式邏輯，這對講求快速回應市場的香港零售與金融業尤其重要。

結論：2026 年，讓元件回歸瀏覽器，讓框架各司其職

Native Web Components 不是要取代 React、Vue 或 Angular，而是要解決一個更根本的組織問題：當企業同時擁抱多個框架，設計系統該放在哪裡？2026 年的答案愈來愈清楚——把最需要共用的 UI 元件下沉到瀏覽器原生層，讓框架專注在應用邏輯與開發者體驗。這不僅是技術選擇，更是香港企業在預算緊縮、人才流動與多渠道壓力下的務實架構策略。

從 design system distribution 的單一來源、browser support 的成熟度，到 migration strategies 的漸進路線，這條路已經有本地案例證明可行。真正的挑戰不在瀏覽器，而在團隊是否願意接受「分層」的思維：該共用的共用，該分開的分開。對 S.C.G.A. Limited 而言，這正是我們協助香港客戶設計跨框架架構時的核心信念——用對的抽象層，換來更長遠的維護自由。