上一份工作交接的時(shí)候我接手了一個(gè)快兩年沒怎么大改的移動端H5項(xiàng)目。照例先翻package.json做技術(shù)摸底看到react-fastclick還躺在 dependencies 里說實(shí)話心里咯噔了一下。這個(gè)庫在我上一個(gè)項(xiàng)目里早就被刪干凈了但等我再仔細(xì)翻代碼發(fā)現(xiàn)項(xiàng)目里保留了不少針對舊內(nèi)核WebView的兼容邏輯于是又猶豫了到底該不該繼續(xù)用 react-fastclick 來應(yīng)對移動端 300ms 點(diǎn)擊延遲這個(gè)問題沒有一句“早就不需要了”那么簡單。如果你也在維護(hù)老項(xiàng)目或者新項(xiàng)目里還在糾結(jié)要不要引入這個(gè)庫這篇文章把 300ms 點(diǎn)擊延遲的來龍去脈、FastClick 的前世今生、以及現(xiàn)代移動端瀏覽器到底做了什么改進(jìn)全部攤開講清楚。你只要對照自己的項(xiàng)目場景就能得出明確結(jié)論不用再為這個(gè)事兒開會討論。1. 300ms點(diǎn)擊延遲的來龍去脈1.1 雙擊縮放是怎么把延遲“發(fā)”給全世界的2007 年 iPhone 發(fā)布的時(shí)候移動端的網(wǎng)頁交互其實(shí)處在一個(gè)非常尷尬的階段。桌面端頁面直接搬到手機(jī)上字太小用戶需要雙擊才能把某個(gè)區(qū)塊放大看清內(nèi)容。為了保證“第一次點(diǎn)擊”和“第二次點(diǎn)擊”能被區(qū)分開——也就是系統(tǒng)需要判斷你到底是想雙擊縮放還是單純地單擊某個(gè)按鈕——Safari 在瀏覽器內(nèi)核里加了一個(gè)等待機(jī)制第一次觸摸事件發(fā)生之后不立刻派發(fā) click而是等 300ms 左右確認(rèn)你沒有第二次點(diǎn)擊才把 click 事件發(fā)出來。這個(gè) 300ms 的等待邏輯本質(zhì)上是給用戶一個(gè)手勢選擇的“猶豫期”。后來 Android 上的 Chrome 和各個(gè)第三方瀏覽器幾乎都復(fù)刻了同樣的行為因?yàn)殡p擊縮放在當(dāng)時(shí)是移動端瀏覽網(wǎng)頁的基礎(chǔ)交互沒有它用戶根本沒法閱讀那些沒為手機(jī)優(yōu)化過的頁面。等移動端H5開發(fā)成為主流之后大家才意識到這個(gè)“猶豫期”在按鈕點(diǎn)擊場景里有多難受。關(guān)鍵點(diǎn)在于300ms 不是手機(jī)硬件的觸摸采樣延遲也不是 WebView 渲染的卡頓而是瀏覽器主動設(shè)置的一個(gè)事件派發(fā)等待窗口。所以它跟手機(jī)性能好壞關(guān)系不大iPhone 15 和 iPhone 6 上如果不做處理點(diǎn)擊事件的延遲感受是一樣的。1.2 300ms延遲真正的影響范圍有多大說起來300ms 好像也就是一眨眼的功夫但在真實(shí)交互里體感非常明顯。你點(diǎn)一個(gè)按鈕按鈕本身沒有反應(yīng)大約 0.3 秒之后才開始觸發(fā)視覺反饋用戶的第一感覺就是“卡”“不跟手”。尤其在做移動端性能優(yōu)化的時(shí)候整個(gè)頁面可能渲染已經(jīng)優(yōu)化到 60fps 了結(jié)果點(diǎn)擊事件還帶著 300ms 的鐵鏈前端的交互體驗(yàn)拉胯優(yōu)化其他東西都白搭。更讓人頭疼的是衍生出來的“點(diǎn)擊穿透”問題。移動端彈窗的關(guān)閉按鈕、輪播圖的切換箭頭、表單里的提交按鈕這些高頻點(diǎn)擊區(qū)域一旦有 300ms 延遲用戶就容易產(chǎn)生二次點(diǎn)擊、甚至三次點(diǎn)擊。層疊結(jié)構(gòu)下上面圖層點(diǎn)擊后消失下面圖層在同位置又接收到了這個(gè) click就出現(xiàn)了關(guān)閉彈窗的同時(shí)把底下某個(gè)按鈕也一起觸發(fā)的情況。這也是為什么當(dāng)年 FastClick 那么火的直接原因——它不只消除延遲還順手解決點(diǎn)擊穿透。從數(shù)值上算一個(gè)用戶一天在移動端H5上點(diǎn)擊按鈕、鏈接、Tab 至少幾十次每次多等 0.3 秒累積起來就是十幾秒的白白等待。這些等待體感不會直接報(bào)錯(cuò)但跳出率會誠實(shí)地告訴你問題有多嚴(yán)重。2. 現(xiàn)代瀏覽器早就把這個(gè)延遲“干掉了”2.1 viewport設(shè)置對了一半問題就沒了很多 React 項(xiàng)目里的public/index.html都寫著一行meta nameviewport contentwidthdevice-width, initial-scale1.0但這行代碼在消滅 300ms 點(diǎn)擊延遲這件事上作用被嚴(yán)重低估了。Google 的 Chrome 團(tuán)隊(duì)在 2013 年就提出了一個(gè)方案當(dāng)頁面設(shè)置了widthdevice-width的 viewport意味著頁面寬度與設(shè)備寬度一致用戶不需要雙擊縮放來閱讀內(nèi)容那瀏覽器可以直接關(guān)閉雙擊縮放檢測自然也就不用等待 300ms。這個(gè)改動真正落地是在 2014 年左右發(fā)布的 Chrome 32 上Android 端的 Chrome 從此開始對“沒有啟用縮放”的頁面取消 300ms 延遲。iOS 的 Safari 走得稍微慢一點(diǎn)從 iOS 9.32016年開始才跟隨這個(gè)邏輯。只要 viewport 里的width等于device-widthSafari 就不會再等待雙擊手勢。到 2017 年主流的 iOS 和 Android 瀏覽器已經(jīng)全部完成了這項(xiàng)調(diào)整。所以你發(fā)現(xiàn)沒有如果你的 H5 頁面從一開始就設(shè)置了正確的 viewport 且沒有開放用戶縮放那 300ms 延遲在現(xiàn)代瀏覽器里根本不存在。讓你產(chǎn)生“點(diǎn)擊不跟手”感覺的往往是別的因素比如頁面卡頓、事件綁定延遲、或者你在舊內(nèi)核的 WebView 里測試。2.2 touch-action: manipulation一行CSS的降維打擊如果擔(dān)心 viewport 沒被正確設(shè)置、或者有些不走尋常路的瀏覽器不認(rèn)這一套那就直接用 CSS 的touch-action屬性來做兜底。html, body { touch-action: manipulation; }這一行代碼告訴瀏覽器這個(gè)頁面允許用戶進(jìn)行 pan 和 pinch 縮放但不要為“雙擊縮放”做等待。瀏覽器收到指令后會直接跳過雙擊手勢檢測點(diǎn)擊事件立刻派發(fā)。相比引入 FastClick這幾乎是零成本、零維護(hù)的降維打擊。touch-action的兼容性也相當(dāng)不錯(cuò)。iOS Safari 9.3、Chrome 36、Android WebView 36 全都支持。如果你的項(xiàng)目最低要兼容到五六年前的移動端瀏覽器這一行 CSS 也基本夠用。唯一的風(fēng)險(xiǎn)是touch-action本身會改變?yōu)g覽器對手勢行為的一些判定但在manipulation這個(gè)值上它允許所有滾動和捏合縮放保留頁面所有默認(rèn)能力,只是移除了雙擊縮放等待適合絕大多數(shù)頁面場景。2.3 Pointer Events新一代點(diǎn)擊事件協(xié)議除了 CSS 層面DOM 事件層面也有了一個(gè)統(tǒng)一方案Pointer Events。這個(gè)協(xié)議把鼠標(biāo)事件、觸摸事件、觸控筆事件統(tǒng)一成一套pointerdown、pointerup、pointermove并且由瀏覽器自己決定是否需要等待手勢判定。在實(shí)際業(yè)務(wù)里絕大多數(shù)現(xiàn)代框架React、Vue的onClick底層仍然綁定的是 click 事件所以 Pointer Events 更多是給那些需要“超低延遲”反饋的場景使用的。比如一個(gè)拖動滑塊、繪圖板、或者高頻點(diǎn)擊的按鈕你可以監(jiān)聽pointerdown而不是click這樣事件在手指接觸屏幕的一瞬間就會觸發(fā)而不是等觸摸結(jié)束再觸發(fā)。這在交互手感上差距非常明顯。當(dāng)然直接全面切換到pointerdown也有新問題它不具備 click 的“容錯(cuò)性”用戶在頁面滑動時(shí)一開始的pointerdown也會被誤判為點(diǎn)擊。所以更務(wù)實(shí)的做法是常規(guī)按鈕繼續(xù)用 click touch-action: manipulation只有對延遲特別敏感的自定義組件才用pointerdown自己控制手感。3. react-fastclick的功勞與歷史包袱3.1 FastClick的工作原理react-fastclick 本質(zhì)上不是 React 組件它是 FastClick 庫的 React 封裝。FastClick 的原始思路可以用一句話概括在瀏覽器還死守著 300ms 延遲的年代不等原生的 click 事件而是自己監(jiān)聽觸摸事件在touchend之后立刻派發(fā)一個(gè)合成 click 事件。它的大致流程是這樣的在 document 上監(jiān)聽touchstart和touchend記錄觸摸開始和結(jié)束的位置與時(shí)間。如果觸摸位移很小基本沒有滑動并且時(shí)長很短比如小于某個(gè)閾值就判定這次觸摸是“點(diǎn)擊”立即在目標(biāo)元素上觸發(fā)一個(gè)合成 click。與此同時(shí)它內(nèi)部還會阻止瀏覽器隨后派發(fā)的原生 click避免同一個(gè)點(diǎn)擊被執(zhí)行兩次。在當(dāng)時(shí)那個(gè)瀏覽器環(huán)境碎片化嚴(yán)重的年代FastClick 確實(shí)解決了很多實(shí)際問題。不管是在 iOS 還是 Android 的舊瀏覽器里引入它之后點(diǎn)擊響應(yīng)立刻跟手用戶體感提升非常明顯。一個(gè)庫能被幾乎全行業(yè)廣泛采用并且一度成為移動端H5項(xiàng)目的標(biāo)配說明它的價(jià)值在當(dāng)時(shí)是貨真價(jià)實(shí)的。3.2 它解決問題同時(shí)也在制造新問題FastClick 被詬病最多的問題集中發(fā)生在表單交互上。iOS 下點(diǎn)擊 input 輸入框偶爾會出現(xiàn)“無法聚焦、需要點(diǎn)多次才彈出鍵盤”的怪異現(xiàn)象社區(qū)里大量 issue 都指向 FastClick 與輸入框聚焦事件狀態(tài)機(jī)之間的沖突。很多人不得不額外加一段 hack 代碼來修復(fù)。第二個(gè)副作用是它會影響瀏覽器原生的一些手勢判定。如果你在頁面上實(shí)現(xiàn)了一個(gè)自定義滾動容器或者拖拽組件FastClick 的 touch 監(jiān)聽有可能把手勢期間的一次“輕微位移”誤判成“快速點(diǎn)擊”結(jié)果拖拽剛啟動就觸發(fā)了點(diǎn)擊回調(diào)。這些場景排查起來非常耗時(shí)間因?yàn)樗皇潜噩F(xiàn)的跟用戶的觸摸軌跡、手指濕度都有關(guān)系。第三個(gè)問題是技術(shù)棧層面的。React 17 把事件委托的掛載點(diǎn)從 document 改成了應(yīng)用的根容器FastClick 攔截 document 級 click 的機(jī)制在某些情況下會和 React 的事件系統(tǒng)產(chǎn)生沖突。前端框架迭代到 React 18、19 之后react-fastclick 這個(gè)庫已經(jīng)基本停更代碼倉庫里的 issue 長時(shí)間沒人回復(fù)。你在 npm install 它的時(shí)候可能還會看到一堆因?yàn)橐蕾囘^老而出現(xiàn)的警告。3.3 react-fastclick的現(xiàn)狀與維護(hù)情況我特意去翻了一下 react-fastclick 和 FastClick 的 npm 及 GitHub 倉庫。FastClick 本體最后一次正式發(fā)布停留在 2016 年之后react-fastclick 的更新節(jié)奏同樣緩慢最近幾年的變化主要是為了適配 React 的版本兼容補(bǔ)丁還是靠社區(qū)貢獻(xiàn)者在維護(hù)。這不代表它已經(jīng)完全不可用你的項(xiàng)目只要鎖住了 React 版本它也許還能跑得不錯(cuò)但問題在于它的設(shè)計(jì)初衷是為了解決“老瀏覽器普遍有 300ms 延遲”的年代問題而這個(gè)前提在今天已經(jīng)不存在了。拿一個(gè)簡單的例子來說今天你新開一個(gè) React 18 的移動端H5項(xiàng)目如果只面向現(xiàn)代手機(jī)瀏覽器占比超過 95%引入 react-fastclick 等于給代碼庫增加了一個(gè)不必要的第三方依賴還額外承擔(dān)了它和 React 事件系統(tǒng)“磨合”的風(fēng)險(xiǎn)。你維護(hù)的每行依賴都應(yīng)該有它存在的理由而不是因?yàn)椤耙郧耙恢边@么用”就一直留著。4. 你的項(xiàng)目到底該不該繼續(xù)用4.1 先做一次項(xiàng)目環(huán)境“體檢”要回答“該不該用”需要先搞清楚你的項(xiàng)目跑在什么環(huán)境下。我建議從下面幾個(gè)角度做一次快速體檢頁面 HTML 里有沒有設(shè)置meta nameviewport contentwidthdevice-width, initial-scale1.0viewport 如果缺失絕大多數(shù)現(xiàn)代瀏覽器依然可能保留雙擊縮放檢測。你的用戶是用系統(tǒng)瀏覽器打開還是內(nèi)嵌在某個(gè) App 的 WebView 里微信內(nèi)置瀏覽器、企業(yè) App 的 WebView它們的瀏覽器內(nèi)核更新時(shí)間一般滯后于系統(tǒng)瀏覽器。你實(shí)際需要兼容的最低內(nèi)核版本是什么如果項(xiàng)目后臺統(tǒng)計(jì)里還有大量 Android 7 以下的老設(shè)備訪問或者公司內(nèi)部 App 的 WebView 是基于多年前的 X5 內(nèi)核那情況要另說。頁面上有沒有大面積的文本縮放需求如果你的產(chǎn)品允許用戶縮放頁面來讀書那就不能直接關(guān)閉瀏覽器縮放能力需要更精細(xì)地管理手勢和事件派發(fā)。一個(gè)很粗暴的判斷方法是把 react-fastclick 從代碼里摘掉加上touch-action: manipulation用真機(jī)跑一輪核心操作流程看點(diǎn)擊反應(yīng)是否滿足產(chǎn)品預(yù)期。如果滿足就不需要再引入如果不滿足再考慮針對性方案。4.2 不同場景下的推薦方案場景推薦方案現(xiàn)代H5項(xiàng)目viewport正確目標(biāo)用戶設(shè)備較新不引庫加一行touch-action: manipulation即可老App內(nèi)嵌WebView內(nèi)核版本接近現(xiàn)代系統(tǒng)瀏覽器不引庫先用 CSS 兜底真機(jī)測試后再做決定老App內(nèi)嵌WebView基于多年前的定制內(nèi)核可以暫時(shí)保留 react-fastclick同步打算治理兼容層頁面需要支持復(fù)雜的滑動和縮放交互不使用 FastClick改用 Pointer Events 自己控制手勢判定React 組件庫自帶觸摸反饋盡量使用組件庫的觸摸事件不額外疊全局庫4.3 如果決定移除怎么安全下線如果你的項(xiàng)目里還在用 react-fastclick經(jīng)過體檢后決定移除我建議按下面步驟操作每一步都做回歸驗(yàn)證不要在凌晨發(fā)布前臨時(shí)刪依賴。第一步全局搜索代碼里所有FastClick或react-fastclick的引用理清楚它是在入口文件統(tǒng)一初始化還是在多個(gè)頁面里分散調(diào)用。很多老項(xiàng)目只在入口文件調(diào)用了一次FastClick.attach(document.body)搜索起來很快。第二步移除依賴并刪除初始化代碼同時(shí)在全局樣式里加上touch-action: manipulation。這里要強(qiáng)調(diào)可以先加 CSS、不刪 JS發(fā)一版到測試環(huán)境觀察沒問題再徹底刪這種灰度策略雖然多了一次發(fā)布但能把風(fēng)險(xiǎn)拆分得很干凈。第三步重點(diǎn)回歸表單交互。盡可能在 iOS 和 Android 的真機(jī)上測一遍輸入框聚焦、鍵盤彈起、下拉選擇這些操作確保沒有出現(xiàn) FastClick 曾經(jīng)帶來的“點(diǎn)一次沒反應(yīng)”的問題。第四步手動觸發(fā)一遍“快速連點(diǎn)”場景。比如彈窗里的“確認(rèn)”按鈕用戶手滑雙擊不要讓同一個(gè)彈窗回調(diào)執(zhí)行兩次。如果產(chǎn)品上確實(shí)有防止誤觸的需求直接加一個(gè)按鈕級別的 loading 狀態(tài)或者節(jié)流處理比依賴事件庫更可靠。5. 移動端點(diǎn)擊相關(guān)的兩個(gè)高頻衍生問題5.1 ECharts在移動端“點(diǎn)不動”“滑不動”是怎么回事很多團(tuán)隊(duì)把 ECharts 圖表嵌到移動端H5里上了線上之后就收到反饋“我點(diǎn)圖上的柱狀圖沒反應(yīng)”“tooltip 不出來”“圖表頁面左右滑動特別卡”。這里要注意ECharts 在移動端的點(diǎn)擊問題和 300ms 點(diǎn)擊延遲其實(shí)是兩回事。ECharts 默認(rèn)使用 Canvas 渲染圖表本身是畫在 canvas 上的一個(gè)“整體”。整個(gè)圖表區(qū)域在 DOM 上只有一個(gè) canvas 節(jié)點(diǎn)ECharts 內(nèi)部會自己計(jì)算你點(diǎn)的是哪根柱子、哪個(gè)坐標(biāo)、哪個(gè)數(shù)據(jù)項(xiàng)。如果你的頁面或者父級容器設(shè)置了某些 touch-action 攔截或者 canvas 的觸摸事件沒有正確綁定到 ECharts 的 zrender 實(shí)例上就會出現(xiàn)點(diǎn)不到數(shù)據(jù)項(xiàng)的情況。比較實(shí)用的排查思路是先在 PC 端用開發(fā)者工具模擬移動端確認(rèn)圖表交互本身是好的。然后到真機(jī)上打開 vConsole在頁面上插入一個(gè)調(diào)試面板監(jiān)看一下 touch 事件到底有沒有觸發(fā)是被哪一層元素?cái)r截了。ECharts 的坐標(biāo)系轉(zhuǎn)換在移動端有時(shí)候會有一點(diǎn)偏移如果你用了tooltip的 HTML 模式還需要給 tooltip 特殊設(shè)置 position否則它可能被 canvas 區(qū)域的 overflow 裁剪掉。對于“圖表區(qū)域滑不動頁面”的問題可以給圖表容器設(shè)置touch-action: pan-y讓垂直方向的滾動交給頁面處理水平方向留給圖表操作。5.2 點(diǎn)擊穿透問題在頁面里的排查技巧點(diǎn)擊穿透是 300ms 延遲時(shí)代最經(jīng)典的衍生 bug。雖然現(xiàn)代瀏覽器已經(jīng)沒有延遲但如果你還在老內(nèi)核 WebView 里或者頁面上有透明遮罩、定位浮層依然可能踩到。我自己排查這類問題時(shí)第一件事是打開 vConsole在移動端瀏覽器里注入一個(gè)調(diào)試面板方便直接看控制臺日志確認(rèn)到底哪個(gè)元素最終接收了 click 事件。排查思路分三步打開 vConsole 后觀察點(diǎn)擊浮層和底層元素時(shí)控制臺輸出的 touchstart、touchend、click 順序然后檢查浮層元素的pointer-events屬性確認(rèn)它是否在某些狀態(tài)下變成了 none導(dǎo)致事件穿透到了底層最后看底部元素的點(diǎn)擊事件綁定是否用了事件委托如果是縮小委托范圍或改用數(shù)據(jù)屬性判斷目標(biāo)來源。常用的修復(fù)方案有三種。第一在浮層關(guān)閉后的同一幀內(nèi)給底層元素臨時(shí)設(shè)置pointer-events: none再在下次點(diǎn)擊時(shí)恢復(fù)這是最直接的方式。第二把浮層關(guān)閉的動畫和事件派發(fā)錯(cuò)開等動畫完全結(jié)束后再允許點(diǎn)擊。第三如果整個(gè)頁面都在統(tǒng)一的觸摸事件模式控制下可以放棄原生 click統(tǒng)一用touchend配合位移判斷來實(shí)現(xiàn)按鈕點(diǎn)擊但這套方案成本更高不建議在常規(guī)頁面上引入。6. 常見問題速查表問題結(jié)論新移動端H5項(xiàng)目還要引入 react-fastclick 嗎絕大多數(shù)不需要除非你的目標(biāo)環(huán)境是老內(nèi)核 WebViewFastClick 還兼容 React 18/19 嗎庫基本停更官方?jīng)]有明確適配社區(qū)有補(bǔ)丁但建議慎用一行 CSS 能替代整個(gè)庫嗎t(yī)ouch-action: manipulation在現(xiàn)代瀏覽器上可以舊內(nèi)核需要測試移除 react-fastclick 后點(diǎn)擊還是慢檢查 viewport、touch-action、頁面渲染性能不要盲目重裝庫ECharts 移動端點(diǎn)擊不生效多半不是 300ms 延遲優(yōu)先排查 canvas 和 touch-action 沖突頁面上輸入框聚焦不穩(wěn)定如果裝了 FastClick先考慮移除它觀察效果部分頁面想兼容極老瀏覽器怎么辦可以做按需降級只在檢測到老內(nèi)核時(shí)動態(tài)引庫這里我想額外提一句在排查移動端點(diǎn)擊問題時(shí)一定要先確認(rèn)問題規(guī)模。如果只是某個(gè)頁面上的某個(gè)按鈕點(diǎn)擊慢大概率是頁面渲染卡頓或者事件綁定位置不對如果是整個(gè)應(yīng)用所有按鈕都有明顯延遲再往 300ms 延遲和瀏覽器內(nèi)核方向考慮。不要一上來就引入一個(gè)全局庫引入了之后再排查問題反而會多一個(gè)變量。另外很多團(tuán)隊(duì)在遷移到 React 18 之后發(fā)現(xiàn) react-fastclick 的綁定行為有點(diǎn)“怪”順手把它換成了 CSS 方案結(jié)果真機(jī)上毫秒級的點(diǎn)擊響應(yīng)反而比之前還好。這也在預(yù)料之中因?yàn)楝F(xiàn)代瀏覽器對 click 的派發(fā)已經(jīng)不再有長等待把原生事件交給瀏覽器去處理永遠(yuǎn)比第三方庫模擬事件更可靠。7. 我踩過幾次坑之后的感想從最早在 jQuery 項(xiàng)目里用 FastClick到 React 項(xiàng)目里用 react-fastclick再到現(xiàn)在新項(xiàng)目里已經(jīng)完全不引入這個(gè)庫我自己經(jīng)歷了完整的三個(gè)階段?；剡^頭來看這類“問題解決庫”的生命周期其實(shí)很有參考價(jià)值它誕生于一個(gè)特定的歷史環(huán)境解決了當(dāng)時(shí)普遍存在、但今天已經(jīng)被技術(shù)棧自身進(jìn)化掉的問題。我現(xiàn)在接到老項(xiàng)目代碼評審看到 react-fastclick 還掛在 dependencies 里時(shí)默認(rèn)流程是先檢查一遍頁面的實(shí)際運(yùn)行環(huán)境做一個(gè)瀏覽器內(nèi)核版本占比統(tǒng)計(jì)然后在測試環(huán)境里直接去掉這個(gè)庫、加上一行 CSS跑一輪自動化和真機(jī)回歸。如果指標(biāo)沒有下降就直接推進(jìn)刪除。如果頁面確實(shí)有相當(dāng)一部分用戶還在用老內(nèi)核 WebView那我會把 react-fastclick 限定在“僅老內(nèi)核環(huán)境按需加載”的降級策略里而不是讓所有用戶都背這份包袱。最后再分享一個(gè)實(shí)用小技巧移動端點(diǎn)擊這件事不要只盯著事件庫。手指按下去到頁面響應(yīng)涉及硬件觸摸采樣、系統(tǒng)手勢識別、瀏覽器事件派發(fā)、DOM 事件回調(diào)、React 狀態(tài)更新與渲染多階段任何一個(gè)環(huán)節(jié)慢都會導(dǎo)致“點(diǎn)擊不跟手”。先打開瀏覽器的 Performance 面板錄制一段時(shí)間用戶操作看看從touchstart到click派發(fā)的時(shí)間差是多少以及點(diǎn)擊后 React 組件狀態(tài)更新耗時(shí)多少。數(shù)據(jù)擺出來誰慢就優(yōu)化誰比直接引一個(gè)第三方庫靠譜得多。