表單裡長出一個彈框：一份 Vue3 動態表單的 schema 設計，把「自己封裝」這條路走到了哪裡

2026年10月18日，掘金上一篇標題樸實的技術長文《Vue3 動態表單支持彈框組件》在工程師社羣裡流傳開來。作者自述是在 IT 人力外包公司工作十餘年的全端開發者，正在為某保險平臺升級核心數據中臺的前端架構，這篇文章是他自研表單渲染引擎 JuanForm 的階段性心得，重點放在最容易被一般表單方案漏掉的一塊：彈框組件也能用 schema 配置出來。

這類文章平常只在工程圈內傳，值得拿來講的原因在於，它把「要不要用低代碼平臺」這個許多技術主管糾結的問題，用一個具體的實作路徑回答了一半。

為什麼保險公司的表單，總是逼人自己造輪子

後臺管理系統的開發者多半有類似經歷：表單頁面一頁接一頁，版面複雜、欄位連動，手寫維護成本高得驚人。作者在文中點出一個產業現實，市面上的低代碼產品多數以雲端服務形式提供，要求客戶把資料遷到平臺上，後續升級維護都受制於第三方。對保險、金融這類資料敏感度極高的行業，這條路往往走不通。

於是折衷方案出現：自己封裝動態表單。用 schema 描述表單結構，渲染引擎負責把配置變成頁面。這個思路不算新鮮，此前我們分析過的釘釘同款審批流設計器開源組件，走的也是同一條「把高頻企業內部元件做成可複用配置」的路線。

彈框為什麼難，又是怎麼被裝進配置裡的

彈框組件的麻煩之處，在於它同時涉及兩件事：畫面渲染與資料生命週期。一個彈框什麼時候打開、關閉時資料要不要回寫主表單、取消時要不要還原，這些狀態邏輯通常得手寫。這篇文章展示的做法，是把 Dialog 也當成 schema 裡的一種 items 類型，和基礎控件、Group 組類型並列，讓彈框與表單其他部分共用同一套資料模型與聯動機制。

文中的示例很貼近保險業務的真實形狀：投保人、被保人、受益人三段資訊，一個「同投保人」開關控制被保人區塊的顯隱，受益人列表可增刪。彈框就是為了處理這種「列表裡的複雜編輯」而存在的。

層與柵格：兩個值得注意的設計取捨

這份 schema 設計有兩處選擇，對想做同類事情的團隊有參考價值。

一是「層（Layer）」的概念。最外層配置物件可以透過 dependsOn 監聽這一層的資料變化，作用類似 Vue 的作用域。這讓欄位聯動不必寫成一堆散落的 watch，而是收攏在配置結構裡，由引擎統一驅動。

二是柵格布局做成行級可配置。預設 16 欄，也可以指定 15、18 等任意數字，欄位可按佔比分配，也可設 auto 自動填滿剩餘寬度，超出總欄數自動換行。這個彈性看似細節，實際上決定了引擎能不能撐住各種「設計師畫出來才發現不對齊」的版面需求。同樣把複雜決策收斂到配置層的做法，也可以對照Vue3 可視化規則引擎的前端取捨：前端只產標準結構，複雜度交給引擎消化。

所以呢

這篇文章的可信度來自它的出發點：不是為了開源打知名度，而是被一個真實的保險中臺專案逼出來的。對於正在評估表單方案的團隊，它至少給出一個可驗證的判斷基準：如果低代碼平臺的資料主權與廠商依賴是硬傷，自研 schema 引擎的投入，可以換到彈框、聯動、柵格這些具體能力上的完全掌控。

當然，作者也只走到「初始完成一個支援複雜聯動的版本」，後續維運成本、TypeScript 型別完備度、與既有元件庫的整合，文中都還沒有答案。這也是自研路線的代價：每一分彈性，都要有人長期付帳。