後端一行不改，50 餘頁零改動搬家：若依換新前端，難在把方言重講一遍

介面、主題、多語系整套翻新，後端與業務頁面原樣保留：一套相容若依的開源前端，把後臺現代化的成本從重寫壓縮成套用加驗證，代價是把若依的方言在新技術棧上原樣重講一遍。

一張重複率很高的後臺臉孔

打開中國企業的內部管理系統，常常撞見同一張臉：左側可摺疊選單，頂部麵包屑，Element 風格的表格、搜尋表單與分頁。往技術棧追下去，答案多半是若依（RuoYi）。這套開源框架的 RBAC 權限體系完整，程式碼簡潔，文件與社羣都成熟，其中的 RuoYi-Vue 幾乎成了後臺管理系統的預設起手式。

問題出在這張臉太久沒換。官方前端多年停留在上一代的技術審美：觀感陳舊，主題定制能力弱，換個主色要改一堆 Less 變數，佈局形式單一，也沒有多語系。於是很多團隊的真實狀態是：後端繼續用若依，前端另起爐竈重寫一遍，權限、字典、程式碼生成這些能力全部要重新對接，等於同一套後臺做了兩次。

10 月 5 日，開發者 niyongsheng 在掘金發文，介紹一套名為 ruoyi-vue-nys 的開源前端，訴求一句話講完：後端零改動，前端整套替換。/getRouters、登入鑑權、字典、程式碼生成等介面全部原樣對接，原有的業務頁面、指令與全域方法直接可用，50 餘個頁面零改動遷移。

換上新殼之後，後臺長成什麼樣

從專案展示的畫面看，這套前端的目標是把當代後臺系統的標配一次補齊。亮色與深色主題齊備，配置抽屜可以一屏調整主題模式、佈局模式、主題色與頁面功能；vue-i18n 讓中英文介面一鍵切換；ECharts 圖表會跟著主題自動換色，監控頁不必另外處理。示範中的使用者管理頁，組織機構樹、搜尋表單、分頁、行內操作一應俱全，深色模式下也維持可讀。

這些能力若依官方前端要嘛沒有，要嘛改起來費勁。對已經用若依跑了好幾年的系統來說，吸引力很直接：視覺與操作體驗整套翻新，後端與資料庫一行不動，也就不必重跑一輪回歸測試。

真正的成本，藏在若依的方言裡

換前端的難處，大部分落在 UI 元件之外。若依的頁面大量依賴全域約定：資料清單從 res.rows 取，檔案匯出靠 this.download，彈窗靠 this.$modal，按鈕權限靠 v-hasPermi 指令。這些寫法在官方範例裡被複製了多年，成了事實上的方言，幾乎每一頁都在講。另起爐竈重寫之所以貴，貴在每頁都要把方言重新翻譯一次。

ruoyi-vue-nys 的解法是把方言原樣搬進新技術棧。它在 src/plugins/ruoyi.ts 寫了一個 setupRuoYiPlugins，把 useDict、download、parseTime、resetForm、handleTree、addDateRange 等方法重新掛回 Vue 3 的全域屬性，插件物件與指令也照原樣提供。專案文中貼出的範例頁，清單取得後把 res.rows 塞進 el-table，匯出靠 this.download 組路徑，整段程式碼不用改就落在新框架裡。這些呼叫點在既有頁面裡超過 250 處，全部要逐一接回。

這條路在軟體工程裡有悠久的譜系。讓 Windows 程式在 Linux 上執行的 Wine，走的就是同一個思路：與其改寫成千上萬支舊程式，不如在新環境裡把舊約定完整實作一次。ruoyi-vue-nys 相容的對象從作業系統介面換成了一個開源框架的約定，規模小得多，邏輯相同。

技術選型全是主流牌

技術棧方面，這套專案幾乎每一張牌都選主流：Vue 3.5 搭 Vite（rolldown-vite）與 TypeScript 5.9，UI 用 Element Plus 2.14 搭 UnoCSS，狀態與路由交給 Pinia 和 vue-router，多語系用 vue-i18n，圖表用 ECharts 6，工程面是 pnpm workspace、ESLint 9 與 vue-tsc。專案以 workspace 切出 5 個 @sa/* 套件，分別負責色板生成、hooks、materials、utils 與 UnoCSS 預設；主題、佈局與路由約定的基礎架構，參考了同為開源的 soybean-admin。

單看每個選項都不新鮮，放在一起看的是時機。Element Plus 與 Vue 3 生態已穩定數年，rolldown-vite 這類建置工具進入可用階段，後臺模板賽道又有成熟範本可借，現在替換前端的成本與風險，都比幾年前低得多。對想導入的團隊，這份選單的意義在於風險位置：學習與招募成本都低，真正要花力氣驗證的，集中在相容層本身，方言有沒有接全、接對。

誰拿到好處，誰接下風險

受益最明顯的是手上有若依系統的企業 IT 與外包團隊。前端重寫原本是一個以月計的專案，現在變成一次套用加上一輪驗證；主題、深色模式、多語系這些過去要自己補的項目，開箱就有。對開發者它也是一份教材，示範遷移專案如何界定相容範圍、量化呼叫點。

風險也必須看清楚。相容層本質上是對若依某個版本的快照，若依後端持續更新，介面約定一旦變動，零改動的承諾就會開始漏氣，這套前端得持續跟版。團隊同時多了一個上遊要追：原本只盯若依官方，現在還要盯這套前端的維護進度，一旦作者停手，相容層自己會變成新的技術債。另外，方言不只官方那套，多數團隊的頁面裡也自己寫過全域方法，這部分沒有人能代勞，得自行接回。

導入前可以依序核對的訊號

若依官方下次改版時，這套前端多快跟上，是第一個值得盯的訊號；跟上得慢，代表相容承諾正在過期。議題回覆速度與修復頻率是第二個，開源相容層最怕維護者淡出。文件是否說明如何接入自行擴充的方言，則決定它能不能撐住真實專案，而不只是示範頁。

真要動手，順序比勇氣重要。先清點自己頁面裡對 download、useDict、$modal、v-hasPermi 的依賴數量，挑客製最重的兩三頁先試，能動再談全面搬家。切換期間讓新舊前端並存，新殼出問題時舊殼還能頂著，這是零改動路線最大的本錢，不該提早放掉。

對整個若依生態來說，這類專案的價值在於示範了框架現代化的另一條路：不必等官方改版，把約定重新實作一次，舊資產就能住進新房子。這條路能走多久，就看相容層跟得上若依幾個版本。