想做一個通知組件，基于MVVM，所有數據走json。列表頁帶過濾和搜索功能。通知詳情帶上一條下一條切換。希望能實現在無過濾和搜索條件下時，在詳情頁內直接做到全局的上一條下一條切換；而在有過濾條件或搜索條件時，上一條下一條在搜索結果列表中切換。方案1：這是我自己想出來的方案。在整個組件初始化時，就把本用戶下的所有通知(ID)取到本地，記到全局[store.list.all]，之后當點擊詳情頁時，前端把要點擊的條目id作為參數做ajax請求，這樣詳情頁就有當前通知id，所有通知id列表。這樣的話詳情頁就可以很輕松的知道上一條的id、下一條的id。當有過濾或搜索條件時，記到全局[store.list.filter]，方法同上。優點：上一條下一條會變得非常容易實現，而且列表頁每次翻頁不需要請求數據。缺點：如果這個用戶的通知列表非常長，那么初始化和搜索的時候，需要請求并記錄到[store.list]中的數據就會非常大，首頁速度可能會非常慢，而且性能會變糟。方案2：公司以前產品的方案。列表頁做分頁查詢，每次請求使用page+row做參數，以一頁row條，查詢第page頁的方式進行查詢（比如page=3,row=10，就意味著查詢第31-40條）。過濾和搜索功能同樣。之前的產品未實現上一條下一條切換。不過按照這個思路繼續搞下去的話，大概會這樣：無過濾搜索條件下，發送當前id作為參數，并帶上next或previous參數，這樣數據庫查詢時可以依靠select * from foo where id = (select min(id) from foo where id > 4)這個方式去查詢。有過濾搜索條件下，這個就比較惡心了，自己沒想出什么好主意，大概是在從列表頁點進詳情頁時保存一下搜索狀態（這個可以做到，返回按鈕就有保存這個狀態），之后在上一條下一條時，除了id、next，也帶上搜索條件做查詢。就是ajax請求api寫起來會比較惡心。優點：列表頁分頁，用戶有多少條通知都不怕。缺點：列表頁翻頁時還要請求和查詢，查詢條件復雜，后端負擔大，詳情頁上一條下一跳的ajax請求會比較難寫。目前就這兩種思路，各有優缺點。大家還有沒有其他思路？