阿里巴巴：服務化管理 7000+ 個項目組件資產

前端早早聊大會，與掘金聯合舉辦。加 codingdreamer 進大會技術羣，贏在新的起跑線。css

第二十八屆|前端 WebGL 專場，2021 年要不要押寶 WebGL 彎道超車，6-26 全天直播，9 位講師(阿里雲/螞蟻/美團/小米等)，報名上車👉 )：html

正文以下

本文是第十六屆 - 前端早早聊組件化專場，也是早早聊第 114 場，來自阿里巴巴 - 遊鹿的分享。web

1、自我介紹

你們好，我是遊鹿，我來自阿里巴巴業務平臺事業-體驗技術-Fusion 中後臺，如今是 Fusion 組件體系的負責人。自 18 年加入阿里巴巴開始，一直專一於中後臺領域的設計師-前端工做協同，主要是前端研發效能的提高。聚焦組件的 DPl 設計、無障礙化、國際化、跨端研發等等。npm

今天我會主要從三個方面進行分享，分別是：前端提效發展史、前端標準規範、物料管理服務化。後端

2、前端提效發展史

今天的主題是「如何借服務化的系統管理團隊的組件資產」，在聊「如何」以前，咱們先看一下阿里是怎麼走這條路的。數組

總結一下阿里這麼多年中後臺的發展，我我的把他們分爲 4 點：統一的技術棧、統一技術組件、物料的推廣、物料的共享：瀏覽器

1.首先統一技術棧：你們應該都知道，阿里前端的技術體系都是 React 的，沒有 Vue 沒有 Angular，這個就是一個統一的技術棧。
2.統一基礎組件：阿里有淘寶、天貓、盒馬、供應鏈、飛豬、支付寶等等 BU，實際上這麼多 BU 在中後臺方向上只有兩個庫，一個是 Fusion 一個是 Antd，除此以外沒有其餘人或團隊從新再作一遍這些底層設施建設。
3.統一物料託管：技術組件的統一，只能解決基礎部分的問題，好比 Button、Input。可是有一些業務屬性明顯、在小範圍內具備廣泛性的組件，例如銀行卡號輸入器，它雖然不適合做爲一個公共的基礎組件，可是適合做爲業務組件，供業務團隊使用。有業務就必定會有業務組件，這些業務組件是須要（也能夠）被統1、體系化管理的，而不是讓每一個團隊都再本身去作重複的工程化處理。這是物料託管方面要解決的問題。
4.最後一步是物料的共享，當物料生態發展到必定蓬勃發展到必定程度以後，其實必定程度上來講，就不該該有新的物料出現了，一切新的需求，均可以用現有的物料去實現。因此說在這種狀況下，徹底能夠考慮說跨團隊的共享，大概是這樣的一條路。

統一組件庫

咱們重點從統一基礎組件庫開始說，先看爲何要統一。其實爲了不重複造輪子，節省業務精力。對業務自己而言，花費大量的時間來構建底層基礎設施並非一件好事，並且前端領域的底層基礎設施都大同小異，不一樣團隊重複構建形成了極大的資源浪費。安全

咱們在這一點上主要看下，阿里是如何作到「使用一套庫就能夠解決幾乎全部 BU 的需求的」。這裏主要介紹Fusion，它在初期的核心能力主要是功能 + 換膚，你能夠理解爲它提供了兩個包：markdown

一個是骨架包就是基礎組件，它包含了好比說 Button、Table 這種組件；
一個是皮膚包，它包含了不一樣的 CSS 樣式。

也就是說每一個業務用的骨架是同樣，可是用的皮膚包是不一樣的，經過皮膚包 + 骨架組件的組合，用戶就能獲得一個適合當前 BU 的一套組件體系。咱們也提供了平臺化的服務，讓各個 BU 的設計師、開發者能夠直接在網站上進行個性化的組件配置，來生產符合業務訴求的皮膚包，配置化能力包括邊、角、線、顏色、陰影等基礎配置，包括各個組件的細節配置等。

這個是比較核心兩個點，固然除此以外還有其餘的能力，好比說一鍵生成對應的 Sketch 物料，供設計師直接使用等。

這個是一個 1.0 版本的架構圖，這套能力的最底層依賴於設計理論的抽象，基於設計方案，抽象出兩套骨架組件 —— PC 端和移動端，如今 PC 端是 React 技術棧，移動端是 Rax 技術棧，這套組件體系是整個 Fusion 的核心，咱們把它叫作骨架組件，再往上一層是主題配置服務，主要供設計師進行操做。

提供一個視頻供你們瞭解這個在線配置的過程。好比說顏色邊角、陰影、線條等等，這個是比較統一的設計，設計上都是規範化的設計，能夠配置這些公共的樣式以外，還能夠配一些組件的樣式。好比說我單獨對 Button 進行設計，把它的邊角從直角風格改爲圓角風格，在這個平臺上都是能夠作到的。剛纔提到說這套平臺的能力依賴底層設計抽象，也就是說它實際上是有限的，但這種有限在中後臺這個場景下其實徹底是夠用的。

按照視頻這麼一通操做下來，它最終會產出一個 npm 格式的主題包。這個包會記錄全部樣式信息，把這個主題包的樣式資源引入業務項目，再訪問頁面，能夠看到頁面樣式發生了變化，這個就是 Fusion 換膚核心能力的演示，也是 1 套組件庫，支撐阿里這麼多 BU 的基礎。

解釋一下原理，換膚能力用到的是 Sass（Sass、Less 都有這些能力）。Fusion 提供的「骨架組件」包括「JS 邏輯」部分，和「Sass 樣式體」部分，「定製化皮膚包」包括了「Sass 變量」部分。咱們把「Sass 樣式體」和「Sass 變量」進行編譯，編譯出一份瀏覽器能夠解析訪問的樣式文件 CSS 文件，業務項目引入 JS、CSS 兩份文件，最終知足不一樣 BU 設計體系的訴求。

基本上在 4 年前，Fusion 就已經具有這個能力了，它不是一成不變的，咱們在這些的基礎上不斷推陳出新，持續迭代，陸續支持了一些其餘功能：

可訪性：主要是對一些訪問 Web 頁面有障礙的人士，例如盲人等作了一些提高，支持屏幕閱讀器等。主要是遵循了 W3C 的一些規範，對組件自己進行優化。
國際化：組件在國際化方面能力也有了比較大的提高，主要表如今比較良好地支持了 RTL（right to left）模式。在一些阿拉伯國家，它閱讀順序是從右到左的。
CSS Variable：同時在今年的時候支持了 CSS Variable 在線換膚能力，藉助瀏覽器的能力，用 CSS 變量去進行換膚，把離線配置改成在線切換。
一碼多端能力：它指的是開發一次，它在 PC & H5 上均可以看，而且 H5 版本的體驗又是接近原生的體驗。由於 Fusion 主要服務的是中後臺，雖然說你們上班的時候仍是用電腦比較多，好比說商品的入庫，商品的上架，下架商品信息填寫等，通常可能電腦端更方便，可是在一些特殊場景下也會有 H5 的需求。好比說盒馬的員工在操做一些商品上下架的時候，使用收集、POS 機等移動設備更多。

Fusion1.0 版本里的換膚能力是須要 Sass 配合的，而瀏覽器其實不識別 Sass 語法，因此才須要經過編譯生成 CSS 文件。而 CSS 變量徹底沒有這個顧慮，它就是瀏覽器識別的，就是 W3C 規範承認的語法。因此說咱們只須要把樣式部分換掉，從一份完整的 CSS 文件換成兩份 CSS 文件，一份是樣式體，一份是 CSS 變量的定義文件，便可。這一能夠知足在線配置的需求，同時 CSS 變量的效率更高，速度更快。

從題目能夠看出「Sass 體系升級爲支持 CSS 變量體系」，也就是說 Fusion 自己仍然須要 Sass 體系，CSS 變量體系並不能徹底取代 Sass（用戶能夠擺脫 Sass）。主要緣由是 Sass 的一些能力目前是 CSS 變量不具有的。

咱們在支持 CSS 變量中遇到的第一個挑戰就是改動必定要小，咱們不但願要重構，目的也不是要把開發環境的全部 Sass 代碼換成 CSS，所以咱們最終定的方案是只經過腳本改變產出。由於用戶只關心他用到的這些文件，好比咱們以前其實就用到給他提供了 CSS 甚至還提供了 Sass、Less（固然從統一阿里生態的角度考慮咱們不推薦用 Less）。所以，基礎組件庫的開發仍然採用 Sass 變量方案，只是在打包階段，經過腳本產生一份 Sass 變量到 CSS 變量的映射，用這份映射與代碼進行編譯，產出帶 CSS 變量的新文件。
遇到第二個問題，用腳本編譯的話會遇到這樣問題，就是 CSS 變量和 Sass 變量雖然都是變量，但實際上他們掌控的範圍是不同的，CSS 變量能力更侷限。舉個例子來講，CSS 變量更準確的名字應當是「自定義屬性」，也就是說它的定位實際上是跟 background、color、font 這些是差很少的，它並不能改變類名，好比說 .next-button 這種類名它其實改變不了的，因此說在掌控範圍上，他是沒有辦法作到的，這是一個坑點。
第三點挑戰點就是函數方法，Sass 有不少 CSS 根本不具有的函數，不存在的函數還比較好解決，有一個坑點是同名函數，例如 rgba() 方法，在 CSS 中，它認爲 rgba(#000, 0.5) 是不合法的，CSS 的特性就是不合法也不會報錯，最多就是不生效。而 Sass 能夠把它正確地識別爲透明度爲 0.5 的黑色。這也是他們的一個差異。
最後在改造過程當中其實會有一些涉及到數學計算的部分，Sass 的數學計算基本能夠對應 CSS 原生的 calc() 有一些坑點介紹給你們：
- calc() 的加減運算符先後要保留一個空格，不然是無效的，可是有一些地方很容易忽略，好比說 calc() 前不容許有負號，-calc(1px) 須要寫成 calc(0px - 1px)；
- calc() 內如有具體值，需寫清楚單位例如 px ，不寫單位在大多數css屬性裏是不合法的（line-height除外）。

這邊列舉一些有意思的小點跟你們分享，你們有興趣想了解更多細節知識點，能夠參考知乎文章，這裏有支持運行時 CSS 變量換膚的整個改造過程《✨FusionNext 可配置能力從 Sass 體系升級爲支持 Css Variable》。

如今阿里內部保守估計的話，有 7000+ 個項目都在使用 Fusion，而後覆蓋了 300 多個團隊，這個只是比較保守的一個統計，實際上應該比這些要更多一些的。能夠看到上面圖中有 4 張圖，他們每一個團隊的風格實際上是不同的，可是用的其實都是一套庫，這也就是統一基礎組件。

物料託管

前端提效發展史第三個是物料的託管，物料託管是什麼、爲何要有物料託管？對於業務來講，光有基礎組件是不夠的，每一個團隊都有一些業務屬性很強的組件，好比說金融團隊可能須要有貨幣匯率轉化的組件，這對於菜鳥的倉儲團隊來講是根本沒必要要的，因此說每一個團隊都會在統一的基礎組件的基礎上，再建設一套本身的業務組件庫，這是在小範圍內的提效方案，這一方案確定是對的。

但從集團層面上看，咱們能爲業務團隊作些什麼，可以讓他們更好的去維護這套組件呢？因此第三點物料託管這條路實際上是一個頂層基礎設施建設的擴展，咱們但願提供一些這樣的頂層的基礎服務，達到讓物料能夠健康迭代的目的。

保證組件資產的健康迭代：業務組件須要有 Demo 示例、API 文檔、常見問題等，不能只有開發者知道怎麼用；
全部資產的可查、可用：新同窗加入後能夠經過平臺，快速熟悉現有資產、加速新人上手速度；
其餘類型資產的沉澱使用：區塊、業務組件、模板等（例如純淨的初始項目，而不是新項目來了去 Copy 老項目再刪改）；
等等其餘問題…...

這些都是屬於底層的技術能力建設，爲了不重複的人員投入，咱們在剛纔 Fusion 的架構基礎上，又增長了一套叫作物料託管的能力，以保證物料健康迭代、可查可用、類型全面等。

物料共享

第 4 點是物料共享，這也是咱們如今正在走的路。當用戶已經用上了物料託管能力，他按照規定的格式，使用了統一的工具開發、發佈了物料，在公共的平臺上能看到找到物料，甚至還能按照團隊進行分類管理。當這些物料都在同一個平臺上以後，咱們其實能夠作更多的事情，好比說物料的共享，跨團隊的共享。

物料的共享不是指拿來就能用，舉個例子餓了麼商家團隊收到一個需求，要作商品的管理系統，可能要包含商品的上架，下架信息填寫等等。這些功能可能已經在淘寶、飛豬團隊都有過一份實現了，邏輯都是相似的，增刪改查。其實這個適合餓了麼的商家同窗徹底能夠站在前人的肩膀上，當他發現別的團隊已經作了這些功能的時候，他能夠把物料拿過來，調整細節，快速複用上線。

由於物料共享的前提實際上是中後臺領域的特色，就是說設計規範統一和前端邏輯高度類似，由於中後臺都是增刪改查表格表單佈局，若是咱們把生態建設得足夠充分了，除了剛纔說的跨團隊之間的建設可能會快一點，那麼後面甚至說可能都不須要設計師和前端了，PD 就徹底能夠在現有的生態體系裏面挑一些他想用的，咱們把能力建設的全面一些，在搭建平臺上直接可讓 PD 去調整參數，就能發佈上線。

這個是咱們正在努力的方向，按照這一方向，咱們把它分紅了三個服務，本地服務、在線標準服務、生態服務，這三個服務分別負責了不一樣的階段，這個能夠說是如今的服務化系統，是咱們管理團隊組建資產的大概結構。

總結

這是阿里巴巴中後臺提效的路線，相信方法論是一致的，這條路對於規模沒有阿里這麼大的公司也是通用的。提煉兩點我的認爲比較關鍵的節點，與各位分享，分別是「規範統一」和「平臺建設」。

3、前端標準規範

規範的體系

上圖爲包含關係，從面到點爲：規範的體系 > 中後臺規範 > 業務組件規範，本次分享也按照這個路徑從面到點的簡單介紹。

一個可能比較全面的前端標準規範都包含哪些內容？簡單梳理了一下，參考上圖。

編碼規約，語句結尾是否要有分號，最後一行是否要換行，縮進是 4 個仍是 2 個空格等。固然也有一些很好用的工具例如 Prettier、ESLint 等來幫助咱們作這些事情，用這些工具插件的前提也是要有規範，這個是編碼規約。
工程規約，例如用戶如何提交代碼，是 Git 仍是 SVN，提交的格式是什麼，commit 信息如何來寫，中文仍是英文，修復 BUG 是否是要帶着 issue 地址，以什麼格式來提交等。
文檔規約，文檔應該怎麼寫？ChangLog 怎麼寫？
根據業務屬性的不一樣，還有 JS Bridge 規範（H5 頁面與各個 APP 端的能力調用）UserAgent 規範（如何識別我究竟是在淘寶，是在 iOS 的淘寶仍是安卓的淘寶）。
中後臺物料規範（多是阿里特有）。
中後臺你們描述協議（多是阿里特有）。

這種前端的標準規範，每一個團隊可能有本身的規範內容，好比說你團隊可能就不須要 JS Bridge 規範的，那就不放進來。有些團隊可能但願把前端和後端的這種 API 規範也放進來，那就放進來。上述規範都屬於前端規範體系，這種必定範圍內的約定是提效的基礎，也是前端規模化、體系化的必要前提。

中後臺規範

今天確實是要講一個比較關鍵的點，就是中後臺物料規範，咱們新增的這些物料規範都是前端的規範體系，這種必定範圍內的約定，是物料託管、流通的基礎，也是前端要想作成規模化體系化的前提。阿里巴巴有太多的中後臺了，天貓有中後臺，淘寶有中後臺、供應鏈有中後臺、盒馬有中後臺、餓了麼有中後臺...... 每一箇中後臺又都是相似的，「中後臺規範」的統一，是阿里集團各中後臺研發平臺可溝通、對話的基礎。

阿里的中後臺規範解決了哪些問題，都有哪些內容？物料託管、物料共享都離不開物料，物料是構成頁面的可複用單元，按照粒度的不一樣可分爲：基礎組件、業務組件、區塊、模板，按照研發模式的不一樣又能夠分爲：ProCode 物料和 LowCode 物料。

規範主要從內容定義和結構劃分上對物料進行了詳細的描述：

劃分元素：阿里的中後臺物料規範中，對前端經常使用的結構進行了劃分，定義了一些常見術語例如業務組件、區塊、模板等；
源碼結構：每一種物料類型都有源碼結構的定義。通常指經過傳統前端開發方式下，一些文件結構、目錄規範等；
低代碼結構：每一種物料類型都有低代碼結構的定義，通常指一套 Schema 描述規範。

頁面結構元素劃分示意圖。

業務組件規範

以「業務組件」爲切入點，簡單介紹源碼 & 搭建的規範現狀。

在將業務組件的源碼規範以前，補充一個知識點，標準的分級。參考 W3C 的規範指定，標準分爲三類：

A：強制規範，必須實現；
AA：推薦規範，推薦實現；
AAA：參考規範，根據業務場景實際訴求實現。

在業務組件層面，好比「目錄規範」、「API 規範」等都是 A 級標準，必須實現；「國際化規範」「主題切換規範」都是 AA 級標準，推薦實現，但不強制。而「無障礙規範」、「轉 sketch 設計稿規範」、「跨端規範」等都是 AAA 標準，根據業務需求實現。這些規範不是實現的越多越好，是須要參考業務實際的，若是業務不須要就不必耗費開發精力去實現。

圍繞兩個 A 類規範展開說明：

目錄規範：阿里巴巴的業務組件源碼的目錄規範如上圖，他要求必須有構建產物的結構（build/lib）、必須有文檔說明（README.md）、必須有可預覽的 demo 等。這個結構能夠你們做爲參考。
API 規範：如圖列舉一些 API 規範。

標準	釋義
通用規則	API 用小駝峯，如 defaultVisible ; 組件名用大駝峯如 Menu、DatePicker
通用命名	約定俗稱的規定命名，例如 size, direction, visible, disabled, htmlType
事件	標準事件或者自定義的符合 w3c 標準的事件，必須以 on 開頭，如 onExpand
表單規範	支持受控模式: value 控制組件數據展示；onChange 發生變化時的回調函數
屬性的傳遞	複合組件內的非核心原子組件，須要經過 xxProps 傳遞參數，如 Select 支持 popupProps
多選枚舉	經過數組枚舉的方式實現，例如 Dialog 支持 closeMode={['close', 'mask', ‘esc']}

這些是業務組件的源碼結構規範，規範統一的好處在於說，淘系的同窗開發的組件，餓了麼的同窗能夠直接拿來使用，由於組件規範統一，它徹底能夠匹配全部 BU 的開發環境，並且組件的使用習慣徹底是一致的，名字不會有任何衝突，也不會使用起來徹底不會有不溫馨的感受。

除了源碼規範以外，阿里的前端中後臺規範，還包括了搭建規範，搭建不是今天的講述重點，若是有想要發展本身搭建體系的公司的話，能夠參考一下。

業務組件的規範分了三種：

基礎信息（A）：描述組件的基礎信息；一般包含包信息、組件名稱、標題、描述等；
屬性描述信息（A）：描述組件屬性信息；一般包含參數、說明、類型、默認值 4 項內容；
能力配置/體驗加強（A/AA）：推薦用於優化搭建產品編輯體驗，定製編輯能力的配置信息。

總結

其實前端的標準規範是像法律同樣的，它是發展變化的，符合大多數人利益的。各位在建設本身團隊規範的時候，能夠參考一下這些意見：

首先標準規範是必定要有的，可是不用說非得一口氣補充完，它是能夠慢慢細化的，例如中後臺標準就是後面加入的。
標準要考慮現有的業務實際。舉個例子，假如團隊內項目在用 Vue 開發，那就不要強行改爲 React，要考慮本身團隊的業務實際。作需求時以業務爲有限，作技術不能爲了升級而升級。
最後一點就是標準的落地是須要工具來保證的，也就是下一章節的物料管理服務化。

4、物料管理服務化

背景和收益

上一章說的規範們，只是一個軟性的約束，怎麼樣能讓你們都遵循規範呢？最好的方式是經過工具，在阿里體系下是如何作這個工具，爲何是它是如今的形態呢？

建設底層設施，有助規範落地：一套體系化、直接可用的服務，有助於規範更好的落地，不然規範就只是一句空談；
集團統一管理，數據驅動研發提效：搭建集團前端統一服務，能夠從全局上把握集團物料的狀態。全部的物料生產數據、消費數據等等，對數據進行分析能夠驅動物料升級與研發提效，反哺業務。

最佳實踐

視頻給你們演示一下如今的成果：

建立物料（本地服務）：建立一個物料的倉庫，選擇倉庫的屬性例如是 React 或者 Rax；選擇物料類型，好比說業務組件，區塊模板等。而後進行一些信息的設定，獲得一個初始化的工程，接着在這個工程裏進行開發。
發佈物料（本地服務）：發佈其實就是 npm 發佈，發佈完了以後。
同步物料（本地服務、物料標準服務）：咱們須要把剛纔發佈的物料與團隊進行關聯。關聯後能夠在平臺上，本身的團隊下，看到剛發佈的組件。參考視頻，能夠看到一個體系化的頁面，用來維護本團隊的全部物料。
挑選物料（生態服務）：在本身團隊物料的根據地上，你既可使用本身的物料，也能夠在物料市場去挑選別人開發的物料。好比我搜索 HelloWorld 這個組件，看到紅色這版以爲很喜歡，我就能夠把它加到本身的物料體系中，這一把它做爲本身團隊物料的一部分去使用它。
使用物料（物料標準服務、生態服務）：在頁面上查看文檔、經過 iceworks 工具等，一鍵安裝到本地項目進行使用。

這個就是完整的一個演示的過程。

如何打造

整個前端組件化的目的是爲了提效，發展到後續其實就是基於物料的提效，物料的管理天然也變成了提效的一部分。

對於沒有計劃、精力打造本身的物料管理服務的團隊，推薦直接使用阿里已經對外開放的物料管理能力 —— fusion.design
對於計劃打造，或者想了解背後原理的同窗能夠參考上圖架構。整體上是提供了兩類能力，一類是平臺化的 SaaS 服務，用戶能夠直接在平臺上建立、維護本身的團隊頁面；一類是 SDK 能力，提供了各類開放API，供有實力、有訴求的團隊引用使用。

5、回顧總結

跟你們回顧總結一下今天的分享，主要是如圖三塊內容。

6、廣告時間

如今是廣告時間，讓咱們一塊兒來建設完善這套服務化系統，創造更多可能吧~ 💃

團隊介紹

阿里巴巴業務平臺事業部的體驗技術團隊，一個熱愛技術，致力於用技術賦能商業，敢於迎接挑戰的大前端團隊~ 👉知乎專欄。

咱們對接的業務：交易、商品、會員、評價、店鋪。簡而言之就是電商體系大閉環的核心業務平臺。除了能讓千萬消費者使用你開發的交易頁面買買買以外，你還有機會讓千萬開發使用你提供的開源庫開發出更多有趣的產品，想要知道天貓、淘寶入駐的千萬商家店鋪頁面是怎樣用搭建的方式就能快速上線的，想知道雙十一背後交易鏈路是怎樣承受住超大流量的，來就對了~

同時，咱們還擁有多個開源產品及其活躍的社區：

Fusion：企業級中後臺UI的解決方案；
ARMS：應用實時監控服務；
BizCharts：企業中後臺的可視化解決方案。

你可能認識的同窗

梓騫：體驗技術團隊的你們長瞭解更多；
秦粵：Node 社區紅人，佈道師瞭解更多；
戊子(榮先乾)：阿里巴巴設計中臺&業務平臺前端中臺技術負責人瞭解更多；
六猴：深耕前端安全體系多年瞭解更多；
風月：一個從中醫藥大學畢業的女前端，現負責數據服務團隊瞭解更多；
潕量(錢陳)： Fusion Design 團隊負責人瞭解更多。

等你來哦

業務平臺事業部-前端技術專家-杭州；
咱們團隊終年招聘 P6/P7/P8 崗位的前端、客戶端同窗，期待與熱愛技術的你一塊兒迎接將來的挑戰，用技術讓商業創新更簡單！！
簡歷投遞地址： youlu.zgy@alibaba-inc.com。

書籍推薦

《驚呆了！哲學這麼好》哲學入門書，像字典同樣解釋了很多哲學名詞，配圖巧妙，還能夠 Get 很多畫圖小技巧~

別忘了第二十八屆|前端 WebGL 專場，2021 年要不要押寶 WebGL 彎道超車，6-26 全天直播，9 位講師(阿里雲/螞蟻/美團/小米等)，點我上車👉 (報名地址)：

全部往期都有全程錄播，能夠購買年票一次性解鎖所有

👉更多活動

點贊，Mark 一下。