同樣一個產(chǎn)品列表組件，設計師拍著胸脯說“復用就完事了”，開發(fā)卻堅持每個頁面要獨立寫一遍。到底聽誰的？我們團隊去年就栽在這個坑里，一個看似完美的復用方案，最后讓四個頁面互相踩踏，差點把項目拖垮。

事情得從我們的送禮平臺說起。收禮人要瀏覽可選的禮物，我們設計了一個產(chǎn)品列表，支持搜索和多種篩選。這個列表出現(xiàn)在好幾個地方：主瀏覽頁、單件送禮彈窗、組合禮包頁面、自動周期送禮設置，還有用戶自建合集。反正就是同一個瀏覽體驗，設計稿上長一模一樣。

一開始我們都覺得，這不就是同一個組件嘛，抽出來共用，完美符合DRY原則。于是興沖沖封裝了一個“通用產(chǎn)品瀏覽組件”，把搜索框、篩選器、列表布局全塞進去，還綁了一套后端接口邏輯。各個頁面只需要傳入幾個參數(shù)就能開箱即用，看起來優(yōu)雅又高效。但問題很快就冒出來了。

先是設計說，單件送禮頁面上得加一個“驚喜提示”小標簽，其他頁面不需要。接著產(chǎn)品經(jīng)理又提，自動周期送禮那里的篩選器得按節(jié)日類型預置幾個快捷按鈕，而別的地方可不能出現(xiàn)這些按鈕。再后來，同一個請求處理函數(shù)，在不同頁面要返回不同的響應結(jié)構，明明調(diào)的是同一個方法，輸出卻得根據(jù)調(diào)用來源變來變?nèi)?。每個變化都往這個復用組件里塞一個布爾值開關：isSingleGift、isAutomated、showSurpriseTip……很快，組件內(nèi)部變成了條件判斷的森林，渲染邏輯也被 if-else 層層包裹。

最恐怖的還在后頭。有一天我們在自建合集頁面改了個篩選重置邏輯，所有測試都跑通了，結(jié)果主瀏覽頁的搜索功能直接崩掉，用戶投訴鋪天蓋地。定位原因發(fā)現(xiàn)，就是那個“通用”組件里的一段共享代碼，被我們修改后影響了一個完全不相干的頁面。從業(yè)務視角看，這兩個頁面根本沒有直接關聯(lián)，卻被一個復用組件強行耦合在一起。這正是我們最不想看到的維護災難。

復盤的時候我們意識到，真正捅刀子的不是“復用”這件事本身，而是我們復用了什么。每一個出問題的案例都有一個共同特征：我們復用的組件里，已經(jīng)內(nèi)置了一部分業(yè)務邏輯。于是我們定下一條粗暴但有效的規(guī)則：不要復用任何哪怕只包含一絲邏輯的組件。可復用的組件必須是純展示性的，不攜帶數(shù)據(jù)調(diào)用、不處理副作用、不包含頁面特有的行為。那些把數(shù)據(jù)裝配進來、處理用戶交互、對接接口的組件，本質(zhì)上是一個個“使用場景”的實現(xiàn)。頁面是一個場景，彈窗是另一個場景，它們天然就該不同，因為“不同”就是它們存在的意義。

按照這個思路我們把系統(tǒng)拆成了兩層。一層是“純UI庫”，里面全是無狀態(tài)的視覺組件，按鈕、卡片、列表容器、輸入框骨架，它們只負責長什么樣，完全不關心數(shù)據(jù)從哪來、點擊后干什么。另一層是“場景組件層”，由具體頁面和彈窗組成，在需要的位置調(diào)用純UI組件，并注入該場景特有的數(shù)據(jù)流和業(yè)務邏輯。頁面A要加驚喜標簽，就在A的場景組件里組合一個純展示標簽進去；篩選器在B頁面需要快捷按鈕，就在B的場景里單獨實現(xiàn)，絕不會干擾到其他地方。

這種做法一開始讓人很不習慣，畢竟看著一堆長得差不多的代碼出現(xiàn)在不同場景組件里，本能就想抽出去共享。但堅持下來后收益非常明顯：每個頁面的邏輯完全隔離，改一個地方的篩選行為再也不會讓另一個頁面的測試變紅；新增一個送禮場景也只需要專注那一個場景的組裝，不用心里默念一堆 if-else 變量的副作用。真正做到了UI視覺層面有復用，業(yè)務行為層面有隔離。

所以回到開頭那個爭論，其實雙方都沒全對，也沒全錯。設計師眼里的復用是指視覺元素一致，開發(fā)擔心的復用是把不該共用的邏輯焊死在一起。這兩件事本來就不該綁在一根繩上。把純UI當積木，把場景邏輯當膠水，膠水別復用，積木隨便搭，這個粗暴的二分法，至少讓我們團隊從“改一個頁面四處冒煙”的噩夢里醒過來了。