遇到 DataGrid 嵌套 DataGrid 導致內部滾輪失效的情況有不少朋友踩過坑我自己第一次碰到也折騰了好一會兒。界面表現(xiàn)很明顯頁面上有一個主表格行里又嵌了一個子表格鼠標一旦移到內部子表格的區(qū)域滾輪滾動時就毫無反應仿佛那個位置的滾輪事件被什么東西吃掉了一樣。其實鼠標事件還在只是被內層控件的滾動機制攔截了沒有傳給外層滾動容器。這個問題的根子在于 WPF 的路由事件機制。具體來說DataGrid 內部有一個 ScrollViewer 負責滾動它處理鼠標滾輪事件時會把這個事件標記為“已處理”。但事件路由一旦被標記為已處理就不會再冒泡給外層元素所以外層的 ScrollViewer 根本接收不到滾輪消息自然也就不會滾動。內層 DataGrid 的高度如果是自動撐開的它自己反而又沒有真正的滾動條可用兩者疊加就出現(xiàn)了“鼠標滾輪失效”的假象。我翻了不少資料也試過幾種方案總體的解決思路是在子 DataGrid 的滾動條到達邊界時把滾輪事件“歸還”給父級滾動容器或者在事件冒泡的早期階段做干預讓父級滾動條優(yōu)先感知滾輪動作。下面我把完整的方案和代碼整理出來順便聊聊我在實操中踩過的坑。1. 問題技術原理解析1.1 為什么嵌套后滾輪會無效先說清楚事件模型的底層行為。WPF 中的鼠標滾輪事件是路由事件路由方向是“隧道 冒泡”兩條路徑。常規(guī)情況下鼠標滾輪事件先走隧道階段從根元素一路向下到達目標元素再走冒泡階段從目標元素逐級向上返回根元素。但對于 ScrollViewer 來說Windows 原生消息在進入 WPF 后會被轉換成 MouseWheelEventArgs 事件該事件的 Handled 屬性會在 ScrollViewer 自身處理滾輪滾動后被置為 true。而路由事件的一個特性就是某個元素把 Handled 設為 true 之后上層元素的 AddHandler 默認不會收到該事件簡單說就是事件“短路”了。內層 DataGrid 的 ScrollViewer 接收并處理了滾輪事件事件就不再往上冒泡外層 ScrollViewer 壓根不知道鼠標正在滾動。如果你還在外層網格里再包了一個 ScrollViewer情況就更復雜兩層滾動容器都在爭搶這個事件。注意即使內層 DataGrid 不顯示滾動條只要它的 ScrollViewer 存在它依然會攔截鼠標滾輪事件。因為 DataGrid 默認模板里就包含一個 ScrollViewer這個內部結構始終存在只是滾動范圍不夠時滾動條不可見而已。1.2 真的是 DataGrid 在“吃”事件嗎不完全是。真正動手處理事件的不是 DataGrid而是它模板里的 ScrollViewer。理解這一點很關鍵因為所有解決方案本質上都是圍繞“內層 ScrollViewer 如何處理滾輪事件”和“外層 ScrollViewer 如何感知滾輪事件”展開的。我可以做一個簡單的實驗來驗證在最外層窗口的 PreviewMouseWheel 事件里加一個調試輸出斷點或日志然后把鼠標放在子 DataGrid 上滾動滾輪。你會發(fā)現(xiàn)在 PreviewMouseWheel 階段事件是可以被捕獲到的但在 MouseWheel冒泡階段事件上外層的處理程序不會觸發(fā)。這表明隧道階段確實經過了外層但事件在冒泡過程中被內層處理并止步了。我們最終要做的就是在事件冒泡被內層“終結”之前通過特殊機制把事件繼續(xù)傳送給外層滾動容器或者是直接接管子層級的滾輪事件自己判斷何時滾動內層、何時滾動外層。2. 三種主流解決方案對比我先后嘗試了三種方案在可控性、代碼量、侵入性上有明顯差異。我建議你先看方案二它在大多數(shù)場景下最省事而且不破壞內部結構的默認行為。方案核心思路優(yōu)點缺點適用場景方案一滾動到邊界后手動觸發(fā)外層滾動監(jiān)聽子表格的 ScrollChanged 事件判斷是否到達邊界再手動滾動外層容器邏輯直觀代碼少需要手動綁定外層容器的名字多嵌套時較繁瑣單層嵌套界面結構固定方案二自定義附加行為Behavior在內層滾動到邊界時動態(tài)尋找父級 ScrollViewer并向父級模擬發(fā)送滾輪事件無需業(yè)務代碼侵入復用性高實現(xiàn)稍復雜需要理解附加屬性和可視化樹通用場景推薦優(yōu)先使用方案三重寫 OnMouseWheel在子 DataGrid 的子類中重寫 OnMouseWheel 方法手動處理邊界穿透面向對象思路適合每個子表格獨立定制必須創(chuàng)建子類使用范圍受限于某一種控件僅針對特定 DataGrid 子類的局部需求這里手動給三種方案排個序日常開發(fā)優(yōu)先用方案二因為它是非侵入式設計一個附加屬性掛上去就能解決多層嵌套問題如果你的場景非常簡單只嵌套了一層方案一也完全夠用方案三適合需要深度定制滾動行為的場合比如子表格擁有獨立的滾動邏輯而不是簡單透傳給父級。3. 基于附加行為的通用解決方案3.1 實現(xiàn)思路拆解方案二的設計意圖很清晰要讓內層滾動容器在不能繼續(xù)滾動時把當前的滾輪事件“轉交”給外層的滾動容器。核心難點在于“什么時候算不能繼續(xù)滾動”以及“怎么轉交”。第一部分判斷何時到達邊界。內層 ScrollViewer 的 VerticalOffset 等于 0 時說明滾到頂部等于 ScrollableHeight 時說明滾到底部。注意 ScrollableHeight 是指內容的實際可滾動高度不是 ExtentHeight。這兩個值都來自 ScrollViewer 的實時依賴屬性。第二部分如何轉交事件。在到達邊界后如果只是讓事件繼續(xù)冒泡結果是無效的因為內層 ScrollViewer 已經把 Handled 標記成了 true。我們需要的就是重新創(chuàng)建一個新的 MouseWheelEventArgs或者在隧道階段提前處理繞過內層 ScrollViewer 的“已處理”狀態(tài)。第三部分找到父級 ScrollViewer 的方法。這里不能直接用 VisualTreeHelper 無限向上遍歷到根節(jié)點因為可能有多層嵌套也可能 DataGrid 外面根本沒有 ScrollViewer。需要做的是“就近查找”向上遍歷可視化樹找到第一個 ScrollViewer 類型并且是被用來滾動外層內容的那個一般是外層 DataGrid 的 ScrollViewer或者手動包的外層 ScrollViewer。判斷滾動到頂部的邏輯要注意邊界條件當 ScrollableHeight 為 0 時內容高度小于可視高度此時滾動條根本不能滾動。如果還強行向上拋事件會造成外層莫名其妙地抖動。所以一定要加一個條件ScrollableHeight 0 時才執(zhí)行邊界判定。3.2 附加屬性代碼實現(xiàn)我選擇實現(xiàn)為一個附加屬性掛載到 DataGrid 或者 ScrollViewer 上都行。考慮到 DataGrid 的 ScrollViewer 是模板內部生成的附加屬性掛在 DataGrid 上更直接一點。using System.Windows; using System.Windows.Controls; using System.Windows.Input; using System.Windows.Media; public static class ScrollViewerBehavior { public static readonly DependencyProperty EnableMouseWheelTransferProperty DependencyProperty.RegisterAttached( EnableMouseWheelTransfer, typeof(bool), typeof(ScrollViewerBehavior), new PropertyMetadata(false, OnEnableMouseWheelTransferChanged)); public static bool GetEnableMouseWheelTransfer(DependencyObject obj) { return (bool)obj.GetValue(EnableMouseWheelTransferProperty); } public static void SetEnableMouseWheelTransfer(DependencyObject obj, bool value) { obj.SetValue(EnableMouseWheelTransferProperty, value); } private static void OnEnableMouseWheelTransferChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { if (d is DataGrid grid) { if ((bool)e.NewValue) { grid.AddHandler(UIElement.MouseWheelEvent, new MouseWheelEventHandler(OnMouseWheel), true); } else { grid.RemoveHandler(UIElement.MouseWheelEvent, new MouseWheelEventHandler(OnMouseWheel)); } } } private static void OnMouseWheel(object sender, MouseWheelEventArgs e) { var grid sender as DataGrid; if (grid null || e.Handled) { return; } var scrollViewer FindVisualChildScrollViewer(grid); if (scrollViewer null) { return; } double offset scrollViewer.VerticalOffset; double maxOffset scrollViewer.ScrollableHeight; if (offset 0 e.Delta 0) { // 向上滾到頂端把事件拋給父級 TransferEventToParentScrollViewer(grid, e); return; } if (offset maxOffset e.Delta 0) { // 向下滾到底部把事件拋給父級 TransferEventToParentScrollViewer(grid, e); return; } } private static void TransferEventToParentScrollViewer(DependencyObject child, MouseWheelEventArgs originalArgs) { var parent FindParentScrollViewer(child); if (parent ! null) { var newArgs new MouseWheelEventArgs(originalArgs.MouseDevice, originalArgs.Timestamp, originalArgs.Delta) { RoutedEvent UIElement.MouseWheelEvent, Source originalArgs.Source }; parent.RaiseEvent(newArgs); originalArgs.Handled true; } } private static ScrollViewer FindParentScrollViewer(DependencyObject child) { DependencyObject current VisualTreeHelper.GetParent(child); while (current ! null) { if (current is ScrollViewer) { return current as ScrollViewer; } current VisualTreeHelper.GetParent(current); } return null; } private static T FindVisualChildT(DependencyObject obj) where T : DependencyObject { for (int i 0; i VisualTreeHelper.GetChildrenCount(obj); i) { DependencyObject child VisualTreeHelper.GetChild(obj, i); if (child is T t) { return t; } T result FindVisualChildT(child); if (result ! null) { return result; } } return null; } }代碼中有幾個關鍵點需要逐一說清楚。AddHandler 的第三個參數(shù)傳 true表示即使事件已經被標記為 Handled也能在監(jiān)聽表單上收到事件。這就是為什么選擇用 AddHandler 而不是直接在 DataGrid 的 MouseWheel 事件上掛處理器。因為內層 ScrollViewer 處理完后 Handled 已經是 true用常規(guī)的事件訂閱方式根本不會進入我們的回調。找到內層 ScrollViewer 用的是 FindVisualChild它是深度優(yōu)先遞歸查找。需要注意的是 FindVisualChild 先查直接子元素再遞歸如果 DataGrid 模板里有多個 ScrollViewer拿到的是第一個不過在實際情況下一個 DataGrid 內部滾動容器只有一個基本不會有歧義。至于向父級傳遞事件這一步不能直接把 originalArgs 重新 RaiseEvent因為該事件已經走完了一次完整的路由生命周期復用它會導致路由信息混亂。正確的做法是新建一個 MouseWheelEventArgs把 Delta、MouseDevice、Timestamp、Source 都復制過去再以父級 ScrollViewer 作為 Source 來重新觸發(fā)這樣才能讓父級滾動容器像收到原生事件一樣正常響應。3.3 XAML 中的掛載方式把這個附加屬性用到界面上非常簡單就是在內層 DataGrid 上加上一行代碼。Grid ScrollViewer DataGrid x:NameOuterGrid AutoGenerateColumnsFalse ItemsSource{Binding OuterItems} DataGrid.Columns DataGridTemplateColumn Header詳情 DataGridTemplateColumn.CellTemplate DataTemplate DataGrid ItemsSource{Binding InnerItems} AutoGenerateColumnsFalse local:ScrollViewerBehavior.EnableMouseWheelTransferTrue DataGrid.Columns DataGridTextColumn Header子項名稱 Binding{Binding Name}/ DataGridTextColumn Header子項數(shù)量 Binding{Binding Count}/ /DataGrid.Columns /DataGrid /DataTemplate /DataGridTemplateColumn.CellTemplate /DataGridTemplateColumn /DataGrid.Columns /DataGrid /ScrollViewer /Grid注意我這里外層也套了一個 ScrollViewer原因是如果外層 DataGrid 的滾動條正常情況下不可見你可能需要手動包一層 ScrollViewer 來確保外層可滾動。當你啟用了附加屬性后鼠標在內層子網格上滾到頂部或底部多余的滾動量就會自動轉移到外層容器上。兩者的滾動方向保持一致體驗會很自然。有一點要提前說主從表格的滾動高度要銜接得上否則會出現(xiàn)“中間有一段空白滾不動”的斷裂感。比如內層表格內容特別長但外層某一行高度有限滾動時內層滾完了、外層還沒到下一個位置可能就會短暫卡頓。這個和方案本身的正確性無關更多是布局設計要配合好。4. 直擊邊界的判斷邏輯細節(jié)邊界判斷是整個解決方案的“魂”。如果判斷不準很容易出現(xiàn)一種奇怪現(xiàn)象鼠標在內層滾輪滾到中間位置時若繼續(xù)向上外層突然開始跟著動但內層其實還有向上空間。這顯然是誤判了邊界條件。正確的判斷邏輯要考慮兩個因素滾輪方向和滾動偏移量。向上滾輪事件是 Delta 大于 0向下是 Delta 小于 0。邏輯應該是方向向上且當前位置在頂部或方向向下且當前位置在底部這兩種情況才把事件拋給父級。如果內層還在可滾動范圍內就讓內層自己消化。有朋友可能會問外層滾動容器在邊界繼續(xù)滾會怎樣答案是不會有效果因為外層 ScrollViewer 自己也有邊界。所以當內層在最底部時往下滾外層如果也在最底部這個重新拋出的事件到達外層后外層也不會發(fā)生滾動這是正?，F(xiàn)象。還有個小細節(jié)有時候 HorizontalOffset 也要處理。如果內層 DataGrid 寬度超過可視區(qū)域會出現(xiàn)橫向滾動條這時候鼠標滾輪不應該操作橫向滾動。但 Windows 常規(guī)的縱向滾輪事件即使在一個橫向可滾動的區(qū)域里默認邏輯也是操作縱向滾動。所以我們保持默認行為就好不必去額外處理橫向滾動。關于 ScrollableHeight 的邊界條件我踩過一個具體的坑當某一行內層表格內容為空比如 ItemsSource 是空集合ScrollableHeight 會返回 0。這時如果用戶在空表格區(qū)域滾動滾輪事件既不會讓內層滾動因為無內容可滾也不會傳給父級因為 offset 0 且 Delta 0 條件成立但 maxOffset 為 0offset maxOffset 成立向下滾動時會傳遞。但如果是向上滾動offset 0 且 Delta 0也會傳遞。這其實是合理的空表格區(qū)域滾輪交給父級沒問題。真正有問題的場景是內層內容很少ScrollableHeight 剛好等于某個非零值且當前 offset 恰好等于 maxOffset。這時候往下滾我們會以為到頭了把事件拋給父級但如果父級此時有較大滾動余量是沒問題的如果父級一開始就在底部那自然沒有多余滾動也合理。所以這個邏輯是自洽的。5. 多層嵌套和動態(tài)加載數(shù)據時的表現(xiàn)項目需求很少會只嵌套一層更常見的情況是外層表格的某一列下面又有子表格子表格里還有子表格形成三層甚至更多層的結構。附加方案的查找邏輯是“就近找父級 ScrollViewer”所以多層嵌套時需要對查找邏輯做一點增強。像上面 FindParentScrollViewer 的寫法從內層網格向上找找到的第一個 ScrollViewer 可能是中間某一層的外層容器。如果還要繼續(xù)向上拋給更上層這個實現(xiàn)就只處理了一層。要做完整的多層傳遞可以寫一個循環(huán)或遞歸查找連續(xù)把所有父級 ScrollViewer 都找出來逐個判斷邊界。我的做法是改成收集一路向上所有的 ScrollViewer每層都判斷一次邊界層層向上傳遞直到某個父級還能繼續(xù)滾動或者沒有更多父級為止。這樣代碼量增加得不多但對復雜嵌套的適應性大幅提升。另外動態(tài)加載數(shù)據也是一個需要注意的場景。當 ItemsSource 綁定的集合發(fā)生變更DataGrid 會自動刷新。此時內層 ScrollViewer 的垂直偏移量可能會自動重置為 0。如果你在滾動過程中更新了數(shù)據源那么邊界判斷就可能基于新的狀態(tài)進行表現(xiàn)上可能會出現(xiàn)一次突然的跳變。這個不是解決方案的問題而是數(shù)據刷新本身的影響。實際操作中如果數(shù)據刷新很頻繁建議在刷新前記錄滾動位置在數(shù)據更新后再恢復對用戶體驗會友好很多。// 獲取滾動位置的輔助方法 public static double GetVerticalOffset(DataGrid grid) { var sv FindVisualChildScrollViewer(grid); return sv?.VerticalOffset ?? 0; } // 恢復滾動位置的輔助方法 public static void SetVerticalOffset(DataGrid grid, double offset) { var sv FindVisualChildScrollViewer(grid); if (sv ! null) { sv.ScrollToVerticalOffset(offset); } }這個輔助方法在數(shù)據刷新前保存 offset數(shù)據刷新后再恢復能避免很大的體驗撕裂感。6. 不使用附加屬性時的簡化版本如果你只是臨時處理一個頁面不想引入附加屬性類也可以采用方案一。我寫一個簡化版代碼直接在內層 DataGrid 的 MouseWheel 事件上處理配合外層 ScrollViewer 的引用。private void InnerDataGrid_PreviewMouseWheel(object sender, MouseWheelEventArgs e) { var grid sender as DataGrid; if (grid null) return; var innerScrollViewer FindVisualChildScrollViewer(grid); if (innerScrollViewer null) return; var outerScrollViewer OuterScrollViewer; // 外層 ScrollViewer 實例引用 double offset innerScrollViewer.VerticalOffset; double maxOffset innerScrollViewer.ScrollableHeight; if ((offset 0 e.Delta 0) || (offset maxOffset e.Delta 0)) { var newArgs new MouseWheelEventArgs(e.MouseDevice, e.Timestamp, e.Delta) { RoutedEvent UIElement.MouseWheelEvent, Source outerScrollViewer }; outerScrollViewer.RaiseEvent(newArgs); e.Handled true; } }要注意這個寫法用的是 PreviewMouseWheel原因是在隧道階段攔截事件趕在內層 ScrollViewer 處理之前拿到事件這樣 e.Handled 的控制權就掌握在我們手里。如果用 MouseWheel 冒泡事件由于內層 ScrollViewer 已經提前處理我們收到的 e.Handled 已經為 true再想傳遞給外層就會很別扭。這種寫法適用于頁面比較固定、層級比較簡單的項目。缺點是外層容器名字寫死在事件處理器里如果界面重構或者外層 ScrollViewer 換掉代碼可能連帶失效。只適合“一次需求、臨時解決”的快速場景。7. 常見問題與排查記錄這個方案我前后在好幾個項目里用過也遇到各種各樣盤外招一樣的問題。我把遇到過的典型問題都記錄下來做個速查表方便遇到同樣現(xiàn)象時快速定位。問題現(xiàn)象可能原因排查思路解決辦法滾輪事件完全沒有響應日志里也看不到任何事件事件被其他元素提前攔截或者 DataGrid 沒有真正獲得鼠標焦點在窗口的 PreviewMouseWheel 掛鉤子打印日志確認是否到達窗口層檢查是否有元素設置了 IsHitTestVisibleFalse 或者有透明覆蓋層擋住了 DataGrid滾到邊界后外層也不滾動外層 ScrollViewer 同樣在邊界或者父級查找邏輯寫錯斷點查看 FindParentScrollViewer 返回的是哪個 ScrollViewer確認外層確實存在可滾動余量否則現(xiàn)象正常內層還沒滾動到邊界外層卻提前滾動了事件在 PreviewMouseWheel 階段被重復處理或者附加屬性應用到了外層 DataGrid 上檢查是否給所有 DataGrid 都掛了附加屬性只給內層嵌套 DataGrid 添加附加屬性滾動方向完全相反把 Delta 正負判斷寫反了打日志查看 e.Delta 符號和想要的滾動方向修正判斷條件向上滾動 Delta 大于 0點擊內層表格的滾動條時仍然無法滾動外層通過滾動條拖動滾動的事件類型不是 MouseWheel而是 ScrollBar 自身的滾動命令滾動條拖拽屬于 Thumb 拖拽范圍無法靠 MouseWheel 事件處理如果期望拖動內層滾動條時外層跟隨需要額外監(jiān)聽 ScrollBar.Scroll 事件數(shù)據刷新后內層滾動位置跳回頂部DataGrid 在 ItemsSource 重置時自動歸零滾動位置檢查數(shù)據綁定是否頻繁刷新刷新前后手動保存/恢復 VerticalOffset有一個比較隱蔽的問題值得單獨說一下如果你的外層 DataGrid 打開了行虛擬化那么內層 DataGrid 在滾動過程中會被銷毀重建。這時 FindVisualChild 可能拿到一個剛剛創(chuàng)建的實例滾動偏移量是 0邊界判斷會誤以為當前位置在頂部/底部導致事件較早就拋給了外層。這種問題往往表現(xiàn)為內層數(shù)據明明還有很長一頁滾動時卻一頓一頓地往外層跳。解決方法是避免在內層 DataGrid 開啟虛擬化或者在外層行 VirtualizationMode 設置為 Recycling 時做額外的滾動位置校驗。在絕大多數(shù)嵌套場景中內層 DataGrid 數(shù)據量不大關閉虛擬化導致的性能損耗可忽略不計。我在外層 DataGrid 上設置 EnableRowVirtualizationFalse 后此類問題就很少出現(xiàn)了。前提是確認外層數(shù)據量本身不大否則會有卡頓風險。開啟虛擬化的情況下ScrollViewer 的 ExtentWidth 和 ViewportWidth 也會動態(tài)變化。邊界判斷依賴的 ScrollableHeight 會受到這些值影響。如果你堅持開著虛擬化建議在 ScrollChanged 事件中實時同步記錄 offset然后用記錄值做判斷不要用臨時的實時值。8. 擴展方向是否要處理觸控屏和慣性滾動到這一步主方案的代碼和常見情景都能覆蓋了。但還有一類容易被忽略的使用場景觸控屏上的手勢滑動操作。觸摸滾動走的是不同于 MouseWheel 的另一套機制Manipulation 操作所以這套附加屬性的代碼在觸屏設備上不會觸發(fā)。我在某個項目里確實遇到過用戶拿觸屏操作時滾動無效的情況。解決方案是在內層 ScrollViewer 上監(jiān)聽 ManipulationBoundaryFeedback 事件當觸摸操作到達滾動邊界時把這個反饋事件傳給外層容器。這個事件專門用于觸控操作到達容器的邊界時給出持續(xù)的反饋提示默認表現(xiàn)是一條波浪線。我們用同樣的附加屬性思路在到達邊界時把 Manipulation 事件轉交出去觸屏上也能有流暢的滾動體驗。grid.AddHandler(UIElement.ManipulationBoundaryFeedbackEvent, new ManipulationBoundaryFeedbackEventHandler(OnManipulationBoundaryFeedback), true); private static void OnManipulationBoundaryFeedback(object sender, ManipulationBoundaryFeedbackEventArgs e) { var grid sender as DataGrid; if (grid null) return; var parent FindParentScrollViewer(grid); if (parent ! null) { parent.RaiseEvent(e); e.Handled true; } }另外鼠標滾輪平滑滾動部分鼠標驅動支持的高分辨率滾動事件在有些電腦上 Delta 數(shù)值比較小而頻率很高此時拋給外層的邏輯依然成立但要注意不要每次小數(shù)量的 Delta 都構造新事件那樣會有大量事件產生?？梢栽诟郊訉傩詢炔考右粋€簡單的時間窗口過濾例如每 30 毫秒最多向外層轉交一次真正的滾動操作。9. 寫在最后的實操心得這個坑我在不同項目里掉進去過兩次第二次才徹底把附加屬性的方案沉淀下來。以我的經驗來看這個方案最大的價值不在于“能用”而在于它不依賴具體的界面命名也不影響原有數(shù)據綁定換成任何一種復雜的嵌套結構都能快速掛載幾乎不需要改動既有業(yè)務代碼。給后來者三個建議。第一先確認你的場景真的是“嵌套導致的事件攔截”最簡單的驗證方式是在外層容器掛一個 MouseWheel 事件處理器看鼠標在內層區(qū)域滾動時它是否觸發(fā)。如果在 PreviewMouseWheel 階段能觸發(fā)在 MouseWheel 階段不觸發(fā)基本可以鎖定方向。第二附加屬性的核心在于 AddHandler 的第三個參數(shù)一定要傳 true這是繞過 Handled 標記的關鍵。第三一旦遇到多層嵌套或者動態(tài)數(shù)據的場景優(yōu)先考慮多層傳遞方案和滾動位置恢復的策略否則調試起來會很痛苦。這個解決方案我在多層級嵌套表格項目、主從明細展示頁、自定義報表中反復驗證過滾輪傳動的連貫性基本能達到原生滾動的手感。如果你還有諸如“多層互相嵌套但中間層也需要獨立滾動”之類的進階需求思路也類似無非是在層與層之間做好事件傳遞鏈。希望這篇文章能讓你少走彎路一次搞定。