摘要：自動化接入和升級方案通過命令行工具提供一鍵接入升級能力，同時集成到團隊腳手架中，大大降低了工程接入和維護的成本。原始代碼經(jīng)過解析器的解析，在管道中逐一經(jīng)過所有規(guī)則的檢查，最終檢測出所有不符合規(guī)范的代碼，并輸出為報告。

代碼規(guī)范是軟件開發(fā)領(lǐng)域經(jīng)久不衰的話題，幾乎所有工程師在開發(fā)過程中都會遇到，并或多或少會思考過這一問題。隨著前端應(yīng)用的大型化和復(fù)雜化，越來越多的前端工程師和團隊開始重視 JavaScript代碼規(guī)范。得益于前端開源社區(qū)的繁盛，當下已經(jīng)有幾種較為成熟的 JavaScript 代碼規(guī)范檢查工具，包括 JSLint、JSHint、ESLint、FECS 等等。本文主要介紹目前較為通用的方案——ESLint，它是一款插件化的 JavaScript 代碼靜態(tài)檢查工具，其核心是通過對代碼解析得到的 AST（Abstract Syntax Tree，抽象語法樹）進行模式匹配，定位不符合約定規(guī)范的代碼。

ESLint 的使用并不復(fù)雜。依照 ESLint 的文檔安裝相關(guān)依賴，可以根據(jù)個人/團隊的代碼風(fēng)格進行配置，即可通過命令行工具或借助編輯器集成的 ESLint 功能對工程代碼進行靜態(tài)檢查，發(fā)現(xiàn)和修復(fù)不符合規(guī)范的代碼。如果想降低配置成本，也可以直接使用開源配置方案，例如eslint-config-airbnb或eslint-config-standard。

對于獨立開發(fā)者，或者執(zhí)行力較強、技術(shù)場景較為單一的小型團隊而言，直接使用 ESLint 及其生態(tài)提供的一些標準方案，可以用較低成本來實現(xiàn) JavaScript 代碼規(guī)范的落地。如果再搭配一些輔助工具（例如 husky 和 lint-staged），整個流程會更加順暢。但對于數(shù)十人的大型前端團隊來說，面向數(shù)百個前端工程，規(guī)模化地應(yīng)用統(tǒng)一的 JavaScript 代碼規(guī)范，問題就會變得較為復(fù)雜。如果直接利用現(xiàn)有的開源配置方案，可能會使工作事倍功半。

規(guī)模化應(yīng)用統(tǒng)一的 ESLint 代碼規(guī)范，會涌現(xiàn)各類問題，根源在于大型團隊和小團隊（或獨立開發(fā)者）的差異性：

技術(shù)層面上：

技術(shù)場景更加廣泛：對于大型團隊，其開發(fā)場景一般不會局限在傳統(tǒng) Web 領(lǐng)域內(nèi)，往往還會涉及 Node.js、React Native、小程序、桌面應(yīng)用（例如 Electron）等更廣泛的技術(shù)場景。

技術(shù)選型更加分散：團隊內(nèi)工程技術(shù)選型往往并不統(tǒng)一，如 React/Vue、JavaScript/TypeScript 等。

工程數(shù)量的增加和工程方案離散化導(dǎo)致 ESLint 方案的復(fù)雜度提升：這樣會進一步增加工程接入成本、升級成本和方案維護成本。

在團隊層面，隨著人員的增加和組織結(jié)構(gòu)的復(fù)雜化：

人員風(fēng)格差異性更大、溝通協(xié)調(diào)成本更高。

方案宣導(dǎo)更難觸達，難以保證規(guī)范執(zhí)行的落實。

執(zhí)行狀況和效果難以統(tǒng)計和分析。

因為存在諸多差異，我們在設(shè)計具體方案時，需要考慮和解決更多問題，以保證規(guī)范的落實。針對上述分析，我們梳理了以下需要解決的問題：

如何制定統(tǒng)一的代碼規(guī)范和對應(yīng)的 ESLint 配置？

場景支撐：如何實現(xiàn)對場景差異的支持？如何保證不同場景間一致部分（例如 JavaScript 基礎(chǔ)語法）的規(guī)范一致性？

技術(shù)選型支撐：如何在支撐不同技術(shù)選型的前提下，保證基礎(chǔ)規(guī)則（例如縮進）的一致性？

可維護性：具體到規(guī)則配置上，能否提升可復(fù)用性？在方案升級迭代時成本是否可控？

如何保證代碼規(guī)范的執(zhí)行？

人員的增加和組織結(jié)構(gòu)的復(fù)雜化，會導(dǎo)致基于管理的執(zhí)行把控失效，這種情況應(yīng)該如何保證代碼規(guī)范的執(zhí)行質(zhì)量？

如何降低應(yīng)用成本？

在工程數(shù)量增加、工程方案離散化的情況，降低方案的接入、升級和執(zhí)行成本能節(jié)約大量的人力，同時也有利于方案落地推進。

如何及時了解規(guī)范應(yīng)用狀況和效果？

為了能在團隊內(nèi)實現(xiàn) JavaScript 代碼規(guī)范的統(tǒng)一，在分析和思考團隊規(guī)模化應(yīng)用存在的問題后，我們設(shè)計了一套完整的技術(shù)解決方案。該方案包括多場景統(tǒng)一的 ESLint 規(guī)則配置、代碼集成交付檢查、自動化接入工具、執(zhí)行狀況監(jiān)測分析等四個模塊。通過各個模塊協(xié)調(diào)配合，共同解決上文提出的問題，在降低維護成本、提升執(zhí)行效率的同時，也保障了代碼規(guī)范的統(tǒng)一。

整體方案的設(shè)計如下圖所示：

多場景統(tǒng)一的 JavaScript 規(guī)范：該模塊是整個方案的核心，借助 ESLint 的特性，通過分層分類的結(jié)構(gòu)設(shè)計，在保證基礎(chǔ)規(guī)則一致性的同時，實現(xiàn)了對不同場景、技術(shù)選型的支撐。

代碼集成交付檢查：該模塊是方案落地執(zhí)行的保障，將代碼靜態(tài)檢查集成到持續(xù)交付工作流中。具體設(shè)計實現(xiàn)上，在保證交付質(zhì)量的同時，也通過定制集成檢查工具降低了開發(fā)者的應(yīng)用執(zhí)行成本。

自動化接入和升級方案：通過命令行工具提供“一鍵”接入/升級能力，同時集成到團隊腳手架中，大大降低了工程接入和維護的成本。

執(zhí)行狀況監(jiān)測分析：通過對工具運行和代碼集成交付檢查過程進行埋點、檢查結(jié)果收集和分析，了解方案的應(yīng)用狀態(tài)和效果。

上文中提出的問題，通過各模塊的協(xié)調(diào)配合能夠得到有效地解決，但具體到各個模塊的實現(xiàn)，仍然需要進一步深入思考，以設(shè)計出更加合理的實現(xiàn)方案。本章將對方案的四個核心模塊進行詳細介紹。

這一模塊主要借助 ESLint 的基礎(chǔ)特性，采用分層分類的結(jié)構(gòu)設(shè)計，提供多場景、多技術(shù)方案的通用配置方案，并使方案具備易維護、易擴展的特性。

在進行 ESLint 配置方案設(shè)計前，我們先看一下 ESLint 的一些特點。

1.插件化

下圖簡單地描述了 ESLint 的工作過程：

ESLint 的能力更像一個引擎，通過提供的基礎(chǔ)檢測能力和模式約束，推動代碼檢測流程的運轉(zhuǎn)。原始代碼經(jīng)過解析器的解析，在管道中逐一經(jīng)過所有規(guī)則的檢查，最終檢測出所有不符合規(guī)范的代碼，并輸出為報告。借助插件化的設(shè)計，不但可以對所有的規(guī)則進行獨立的控制，還可以定制和引入新的規(guī)則。ESLint 本身并未和解析器強綁定，我們可以使用不同的解析器進行原始代碼解析，例如可以使用 babel-eslint 支持更新版本、不同階段的 ES 語法，支持 JSX 等特殊語法，甚至可以借助 @typescript-eslint/parser 支持 TypeScript 語言的檢查。

2.配置能力全面、可層疊、可共享

ESLint 提供了全面、靈活的配置能力，可以對解析器、規(guī)則、環(huán)境、全局變量等進行配置；可以快速引入另一份配置，和當前配置層疊組合為新的配置；還可以將配置好的規(guī)則集發(fā)布為 npm 包，在工程內(nèi)快速應(yīng)用。

3.社區(qū)生態(tài)較為成熟

開源社區(qū)中基于 ESLint 的項目非常多，既有針對各種場景、框架的插件，也有各種 ESLint 規(guī)則配置方案，基本可以涵蓋前端開發(fā)的所有場景。

基于 ESLint 的插件化、可層疊配置特性，以及面向各種場景、框架的開源方案，我們設(shè)計了如下圖所示的 ESLint 配置架構(gòu)：

該配置架構(gòu)采用了分層、分類的結(jié)構(gòu)，其中：

基礎(chǔ)層：制定統(tǒng)一的基礎(chǔ)語法和格式規(guī)范，提供通用的代碼風(fēng)格和語法規(guī)則配置，例如縮進、尾逗號等等。

框架支撐層（可選）：提供對通用的一些技術(shù)場景、框架的支持，包括 Node.js、React、Vue、React Native等；這一層借助開源社區(qū)的各種插件進行配置，并對各種框架的規(guī)則都進行了一定的調(diào)整。

TypeScript 層（可選）：這一層借助?typescript-eslint，提供對 TypeScript 的支持。

適配層（可選）：提供對特殊場景的定制化支持，例如 MRN（美團內(nèi)部的 React Native 定制化方案）、配合 prettier 使用、或者某些團隊的特殊規(guī)則訴求。

具體的實際項目中，可以靈活的選擇各層級、各類型的搭配，獲得和項目匹配的 ESLint 規(guī)則集。例如，對于使用 TypeScript 語言的 React 項目，可以將基礎(chǔ)層、框架層的 React 分支、以及 TypeScript 支撐層的 React 分支層疊到一起，最終形成適用于該項目的 ESLint 配置。如果項目不再使用 TypeScript 語言，只需要將?ts-react?這一層去掉即可。

最終，形成了如下所示的 ESLint 配置集：

考慮到維護、升級和應(yīng)用成本，我們最終選擇將所有配置放到一個 npm 包中，而不是每種類型分別設(shè)置。仍以使用 TypeScript 語言的 React 項目為例，只需在工程中進行如下配置：

// 需要安裝 typescript、eslint-plugin-react、@typescript-eslint 等插件
module.exports = {
  root: true,
  extends: [
    // 因為基礎(chǔ)層是必備的，所以框架層默認引入了對應(yīng)的基礎(chǔ)層，不需再多帶帶引入 eslintrc.base.js
    "eslint-config-xxx/eslintrc.react.js",
    "eslint-config-xxx/eslintrc.typescript-react.js"
  ]
}

這種通過分層、分類的結(jié)構(gòu)設(shè)計，還有利于后期的維護：

對基礎(chǔ)層的修改，只需修改一處即會全局生效。

對非基礎(chǔ)層某一部分的調(diào)整不會產(chǎn)生關(guān)聯(lián)性的影響。

如需擴展對某一類型的支持，只需關(guān)注這一類型的特殊規(guī)則配置。

眾所周知，TypeScript 類型的項目使用 TSLint 進行代碼檢查，也是一種簡單、便捷的方案。但在本方案中我們依舊選擇了：eslint?+?@typescript-eslint/parser?+?@typescript-eslint/eslint-plugin?的組合方案。主要有以下幾點原因：

ESLint 的規(guī)則配置更加詳細全面，覆蓋更加廣泛。

采用了分層分類的架構(gòu)，能夠保證即使框架或語言不同，也能在基本語法、風(fēng)格層面保持規(guī)則的一致性，這樣有利于團隊內(nèi)不同技術(shù)選型項目的風(fēng)格統(tǒng)一。

@typescript-eslint 方案持續(xù)迭代，問題響應(yīng)非常迅速，對 TSLint 相關(guān)的規(guī)則基本提供了對等的實現(xiàn)。

根據(jù)最新消息，TypeScript在?2019 路線圖?中明確表明后續(xù)對 Lint 工具的支持和建設(shè)會以對 ESLint 進行適配的方式為主。

基于團隊對工程化基礎(chǔ)設(shè)施的建設(shè)，將代碼規(guī)范靜態(tài)檢查與開發(fā)工作流集成，保證代碼規(guī)范的落實。

通常而言，工程接入 ESLint 后，可以在開發(fā)的同時借助編輯器集成的 ESLint 檢查提示能力（例如 VSCode 的 ESLint 插件），實時發(fā)現(xiàn)和修改不符合規(guī)范的語法錯誤和風(fēng)格問題。但這仍不能避免因一些主觀因素或疏漏造成的規(guī)范執(zhí)行不到位，所以我們考慮在開發(fā)工作流的特定節(jié)點自動執(zhí)行代碼靜態(tài)檢查，阻斷不合規(guī)范代碼的提交或交付。

集成靜態(tài)檢查的開發(fā)工作流節(jié)點有很多，我們主要參考以下兩種方案：

代碼提交檢查：在代碼 Commit 時，通過 githook 觸發(fā) ESLint 檢查。其優(yōu)點在于能實時響應(yīng)開發(fā)者的動作，給出反饋，快速定位和修復(fù)問題；缺陷在于開發(fā)者可以主動跳過檢查。

代碼交付檢查：在代碼交付（借助 CI 系統(tǒng)的交付流程功能）時，在代碼檢測平臺中對代碼進行 ESLint 檢查，檢測不通過則阻斷交付。其優(yōu)點在于能夠強制執(zhí)行，可在線追蹤檢測報告；缺陷在于離開發(fā)者的開發(fā)環(huán)境太“遠”，開發(fā)者響應(yīng)處理成本較高。

如果將兩者進行結(jié)合，可能會事半功倍，效果如下圖所示：

常用的代碼提交檢查方法一般是?husky?與?lint-staged 結(jié)合，在代碼 Commit 時，通過 githook 觸發(fā)對 git 暫存區(qū)文件的檢查。但考慮到團隊現(xiàn)有工程數(shù)量龐大、存在大量行數(shù)較多的文件，雖然?lint-staged?策略能夠降低部分成本，但仍稍顯不足。為此，我們對該方法進行優(yōu)化，定制了本地代碼提交檢查工具?precommit-eslint，其核心特點是：

將增量檢查執(zhí)行到代碼行這一粒度，支持 Warn 和 Error 兩個檢查級別。

只需將工具安裝為工程的依賴，無需任何配置。

減少了 pre-commit hook 中植入腳本的侵入性。

進行了執(zhí)行狀況埋點和采集。

使用效果如下圖所示：

在美團，我們使用自主開發(fā)的 CI 系統(tǒng)，并在獨立部署的 Sonar 系統(tǒng)上定制化實現(xiàn)了相應(yīng)規(guī)則，基本可以滿足訴求，這里就不再贅述。對于獨立的團隊，基于 ESLint 提供的工具，可以很容易的實現(xiàn)使用 Node 快速搭建一個代碼檢測服務(wù)或平臺，大家有興趣不妨一試。

這個模塊主要通過 CLI 工具提供方案自動化接入的能力，降低工程接入和升級的成本。如果不借助自動化工具，在工程中接入上述方案還是有一定的工作量和復(fù)雜度的，大致步驟如下：

安裝 Eslint。

根據(jù)項目類型安裝對應(yīng)的 ESLint 規(guī)則配置 npm 包。

根據(jù)項目類型安裝相關(guān)的插件、解析器等。

根據(jù)項目類型配置 .eslintrc 文件。

安裝代碼提交檢查工具。

配置 package.json。

測試及修復(fù)問題。

在這個過程中，特別需要注意依賴的版本問題：依賴之間的版本兼容性，例如?typescript?和?@typescript-eslint/parser?之間的兼容性；依賴對規(guī)則的支持性，比如某個版本的插件中去除了對某個規(guī)則的支持，但規(guī)則配置中仍然配置了該規(guī)則，此時配置就會失效。對于 ESLint 不熟悉的開發(fā)者而言，在配置的過程中都會或多或少遇到兼容性、解析異常、規(guī)則無效等問題，反復(fù)排查和定位問題會浪費大量的精力。

因此，在設(shè)計開發(fā)自動化接入工具時，我們綜合考慮了操作步驟、依賴版本、規(guī)則集和工程方案的兼容性，設(shè)計了如下的工作流程：

該工具流程簡單，不管什么開發(fā)場景和框架選型，繁瑣的接入流程都可以簡化為一條命令，需要配合工程方案升級時同樣如此。如下圖所示，執(zhí)行該命令后項目就完成了 ESLint 的接入，使用統(tǒng)一的規(guī)則規(guī)范編碼，同是在代碼提交時自動進行增量檢查：

統(tǒng)計分析的主要目的是掌握方案應(yīng)用執(zhí)行狀況和效果，理論上應(yīng)當支持工程和大盤兩個視角，如下圖所示：

執(zhí)行情況分析其實并不復(fù)雜，核心是信息采集和分析。在本方案中，信息采集通過 precommit-eslint 工具實現(xiàn)：在 git commit 觸發(fā)本地代碼檢查后，腳本會把檢查結(jié)果（包括檢查是否通過、錯誤或警告信息的數(shù)量級別等）上報；信息的統(tǒng)計分析借助日志上報分析平臺實現(xiàn)，美團使用的是 CAT 平臺（如果團隊或公司沒有專門的平臺，可以在上文提到的代碼檢測服務(wù)平臺中實現(xiàn)這部分功能）。為了便于數(shù)據(jù)的聚合分析，我們將一次代碼提交檢查中出現(xiàn)的問題數(shù)量進行了分級：

檢查通過：檢查無代碼規(guī)范錯誤。

錯誤 1 級：檢查出代碼規(guī)范錯誤數(shù)量小于 10 個。

錯誤 2 級：檢查出代碼規(guī)范錯誤數(shù)量在 10 - 100 個之間。

錯誤 3 級：檢查出代碼規(guī)范錯誤數(shù)量在 100 - 1000 個之間。

錯誤 4 級：檢查出代碼規(guī)范錯誤數(shù)量大于 1000 個。

比如下圖中，201903 第一周的代碼提交檢查結(jié)果統(tǒng)計（綜合采樣率 0.2），很明顯，所有檢查失敗的提交中，錯誤數(shù)量在 10 個以內(nèi)的占比最大，修復(fù)成本不高。

1.提交檢查異常分布（僅篩選檢查未通過信息）

2.提交檢查警告信息分析

除此之外，還可以對單一工程，在更細的時間粒度上去觀察提交檢查的執(zhí)行情況。

效果質(zhì)量主要分析工程質(zhì)量的變化：一方面可以通過代碼檢查執(zhí)行通過率變化趨勢、檢查結(jié)果分布去看持續(xù)的生產(chǎn)流程中，代碼質(zhì)量是否有所提升；另一方面，由于代碼檢查采用增量模式，需要對工程代碼進行整體分析，得到工程整體的不規(guī)范代碼占比及變化趨勢，從而從工程維度分析判斷質(zhì)量效果（涉及到權(quán)限相關(guān)問題，目前團隊中未采用工程分析的方法）。具體的分析會在方案應(yīng)用效果中一并進行介紹。

除了上述整體方案外，為保證開發(fā)者使用更方便，我們還進行了一些配套工作：

持續(xù)維護升級：以每月一版的方式持續(xù)迭代升級，解決應(yīng)用中的問題、規(guī)則爭議，以及支持新的規(guī)則或方案。

工程化集成：整套方案可以無縫接入到各個團隊的腳手架工具中，自動成為團隊的默認方案，在工程初始化階段即可完成接入。

官網(wǎng)建設(shè)：提供詳細的使用文檔，包括規(guī)則信息、接入方法，并且對每個版本提供規(guī)則、環(huán)境依賴、changeLog 等詳細說明。

常見使用問題：更新維護FAQ，幫助后續(xù)接入者快速查找并解決問題。

目前，該套方案已經(jīng)接入美團外賣、餐飲平臺、閃購、榛果、金融等多個團隊，基于埋點統(tǒng)計分析，我們（基于2019年2月份最后一周統(tǒng)計數(shù)據(jù)分析，綜合采樣率0.2）得到了如下數(shù)據(jù)：

截止到2019年2月底，該方案已接入超過 200 個前端工程。

集成檢查（增量）每天執(zhí)行接近 1000 次。

集成檢查（增量）平均每天檢查出錯誤約 20000-25000 處。

集成檢查代碼質(zhì)量：平均通過率為 75.562%，錯誤 1 級的比率為 15.644%，在所有未通過檢查中占比 64.015%。

同時，我們持續(xù)統(tǒng)計上述數(shù)據(jù)的變化趨勢，跟蹤代碼質(zhì)量提升效果，以2018年12月到2019年3月的數(shù)據(jù)為例（截止2019年3月第一周，以周為時間統(tǒng)計尺度）：

從圖中可以看出，最近三個月檢查通過率整體呈上升趨勢，但 2019 年 1 月的第 2 周和第 3 周集成檢查通過率有明顯下降。分析項目信息發(fā)現(xiàn)，在 2019 年 1 月的第 2 周有一批新項目接入，代碼檢查規(guī)范檢查出幾十個錯誤。但整體來看，目前集成檢查通過率基本穩(wěn)定在 75% - 80%，從變化趨勢看仍有上升空間。

方案實施之后，我們做了一個用戶調(diào)研，發(fā)現(xiàn)整體方案的運營正在發(fā)揮著正向的作用。一方面，在一定程度上提升了多人協(xié)作的效率，無論是共同維護一個工程還是在多個工程間切換，避免了代碼風(fēng)格不一致帶來的可讀性成本和格式化風(fēng)險；另一方面，會幫助大家發(fā)現(xiàn)和避免一些簡單的語法錯誤。

該方案已經(jīng)穩(wěn)定應(yīng)用，除了現(xiàn)有功能，我們還在思考是否可以更進一步的優(yōu)化，提供更豐富的能力。由此規(guī)劃了一些仍未落地的方向：

擴展支持 HTML 和 CSS 的代碼風(fēng)格檢查：雖然近幾年前端框架、組件庫的建設(shè)一定程度上減少了業(yè)務(wù)開發(fā)中（尤其是中后臺業(yè)務(wù)）對 HTML 和 CSS 的需求，但是規(guī)范 HTML 和 CSS 的代碼風(fēng)格仍是必要的。基于此，可以用同樣的思路將 HTML 和 CSS 的代碼靜態(tài)檢查方案集成到當前的方案中，不再局限于 JavaScript（或 TypeScript）。

進一步的封裝：目前整體方案會將所有依賴和配置暴露在工程內(nèi)，如果將其完全封裝在一個工具內(nèi)會更便于應(yīng)用，但難點在于兼顧靈活性、對編輯器的支持等問題。

增加工程維度的代碼質(zhì)量趨勢分析：目前代碼檢查策略是增量檢查，可以對接入的工程定期全量檢查，基于時間線分析工程的代碼質(zhì)量變化趨勢。

進一步深入分析檢查結(jié)果和統(tǒng)計數(shù)據(jù)，發(fā)現(xiàn)一些潛在問題，為推動開發(fā)質(zhì)量提升提供輔助，如：

統(tǒng)計開發(fā)者在工程中關(guān)閉或調(diào)整的規(guī)則，分析占比較高的規(guī)則被關(guān)閉的原因，進而調(diào)整規(guī)則或推動規(guī)則的執(zhí)行。

統(tǒng)計分布檢查出錯誤的規(guī)則分布，梳理出最常出問題的代碼規(guī)則，發(fā)布對應(yīng)的最佳實踐或手冊。

以上是美團外賣團隊在 ESLint 方案規(guī)模化應(yīng)用過程中的一些實踐，歡迎大家提出建議，一起溝通交流。

宋鵬，美團外賣事業(yè)部終端研發(fā)工程師。

美團外賣事業(yè)部終端團隊，負責(zé)的多個終端和平臺直接連接億萬用戶、數(shù)百萬商家和幾萬名運營與銷售，目標是在保障業(yè)務(wù)高穩(wěn)定、高可用的同時，持續(xù)提升用戶體驗和研發(fā)效率。

在用戶方向上，構(gòu)建了全鏈路的高可用體系，客戶端、Web前端和小程序等多終端的可用性在99%左右；跨多端高復(fù)用的局部動態(tài)化框架在首頁、廣告、營銷等核心路徑的落地，提升了30%的研發(fā)效率；

在商家方向上，從提高進程優(yōu)先級、VoIP Push拉活、doze等方面進行保活定制，并提供了Shark、短鏈和Push等多條觸達通道，訂單到達率提升至98%以上；

在運營方向上，通過標準化研發(fā)流程、建設(shè)組件庫和Node服務(wù)以及前端應(yīng)用的管理與頁面配置等提升10%的研發(fā)效率。

團隊有多個崗位正在招聘，歡迎加入我們，聯(lián)系郵箱 tech@meituan.com ，注明 “外賣終端團隊”。