如果寫一個web論壇中的一個帖子，我應該怎樣使用ajax獲取從後台得到的信息最為合理？

01-29

本人是新手開發者，請各位多多包容。
該問題沒有討論技術上的問題，只是討論在web開發中應該保持一種怎麼的思路
1 假設後台能以任意形式(比如一個ajax返回所有以下的信息，只要前端開發者不覺得麻煩)給予我任何我想要的信息(帖子內容，帖子回復，回復的回復，個人信息。。。)，我應該怎麼布置ajax獲取？(一個ajax獲取所有信息，前端開發者慢慢布置？按照信息分類，使用多個ajax獲取各個類別的信息？)
2 假設後台只能以分類的方式給予前端開發者信息，那麼作為前端開發者有沒有能提高性能的方法？
(在這情況下，我的思路是

1. 一個ajax獲取帖子的內容
2.一個ajax獲取帖子的評論，用for循環輸出每一個的評論
3.在第二步中，對每一個帖子使用一次ajax獲取該評論的回復，如果有十個評論，那麼除了要用一次ajax獲取所以評論外，還要用十次的ajax獲取每個評論的回復
這樣寫會導致要多次執行ajax，導致網頁載入非常緩慢，所以我很想知道，大型門戶，比如某貼吧是如何再載入如此多的信息下載入速度確這麼快)
求大神指點迷津

如果所有人都能像你這樣提問題，就很欣慰。

首先，這是一個程序設計問題，某種意義上也是一個架構問題，請記住沒有標準答案。

前面的回答已經提到，把用戶體驗設計成分步信息呈現，即不一次性展示所有內容，而是在用戶交互的導引下，一部分一部分地載入相關數據，這很常用。

優點是架構靈巧，簡單，前後端都只需要關注小操作，而不需關注超級大操作（數據讀取）。

缺點是SEO不友好，搜索引擎可能只會index第一批次載入的數據。

其實這類問題就是受這兩個因素左右，在效率和SEO間找到平衡，平衡只依賴你的項目，沒有標準答案。如果SEO對你至關重要，那麼你應該放棄這種方案，而是在後台完成所有數據裝載，在後台渲染出頁面，前端只設計用戶交互部分的介面。

如果你知道哪個部分的數據對SEO直觀重要，就應該儘可能早地（在伺服器端渲染）這部分內容，剩下的可以AJAX處理。

沒有人規定一個應用只可以前端渲染或者只可以後端渲染，所以不要拘泥，保證用戶體驗，保證SEO效果才是價值所在。

不必過於擔心AJAX請求數太多，通常這不是問題，先保證第一部分數據最快載入，後續數據對用戶的價值相對較弱，所以你有空間選擇。

可以多AJAX並行載入，可以讓API設計batch（批量）介面來優化，即若AJAX請求過多，那麼可以設計成一次AJAX請求傳多個ID，讓API返回批量數據，然後前端處理之。

這是個泥人兒，怎麼捏看你的。

我只能根據我理解的說下我的思路

以下說明中 ... 為省略，實際需要展示的數據以需求為準

// 進入論壇第一次請求， // 獲取論壇列表每篇帖子的標題，唯一的ID等信息 // 然後渲染到頁面上展示帖子列表 { "data":[ { "帖子id": "123", "帖子標題": "測試123", "回復量": 123, "點擊量": 321, ... }, { "帖子id": "234", "帖子標題": "測試234", "回復量": 234, "點擊量": 432, ... }, ... ], ... }


// 你點擊了列表裡某個帖子

// 發送一個請求給後端request:

{

    "帖子id": "123"

}
// 從後端接收返回帖子數據

// 和當前頁碼內每篇帖子的回復

// -----------------

// 如果是下拉載入的話，其實也是一樣的

// 發送一個  帖子id  和  當前頁碼  的數據給後端

// 然後後端返回給你數據之後你把獲得的數據繼續渲染到頁面上就行

// 不要告訴我你連jq里.append()這個方法都不知道是啥

{ "data": [ // 1樓就直接展示樓主帖子內容 { "是否1樓": true, "用戶id": "1234567", "內容": "XXXXX" }, // 不是1樓就展示回復樓主的信息 { "是否1樓": false, "用戶id": "7654321", "內容": "XXXX", // 回復少的話可以直接展示 // 回復多的話那就分頁展示 // -------------------------------- // 點擊回復第二頁的話,發送回復id 和回復頁碼數給後端 // 然後返回第二頁的回複信息渲染到該樓層的回復部分dom節點 "回復": { "回復id": "1111" "回復內容": [ { "用戶id": "12345", "內容": "XXXXXXX", }, { "用戶id": "54321", "內容": "XXXXXXXX", }, ... ], "回復頁碼": 1 } }, ... ], "頁碼page": 1 }

1、實際就是，進入論壇一個ajax請求，獲取當前頁帖子列表

2、點擊某篇帖子，一個ajax請求，獲取當前頁的帖子內容和回複信息

可能產生ajax的行為：

1、下拉滾動條或者點擊帖子列表某頁後（根據頁面設計來，其實都可以理解為分頁顯示，只是不同形式展示），

發送ajax，獲取下一頁或者某一頁帖子信息

2、點擊某個樓層回復頁碼，發送ajax，獲取當前樓層回復某一頁的回複信息

看你應用場景，如果評論總是跟著帖子出現的，那麼一起返回，評論可以默認返回幾條。如果一般是看見帖子，點查看評論才看到，那就分開。

你看網易新聞，每個新聞默認帶幾個評論，那麼獲取帖子時候可以直接返回幾個評論，點評論的時候再獲取更多的評論。

當然這樣操作會感覺不優雅，尤其用restful介面，感覺不倫不類。但是用戶體驗是第一位的，一切提升用戶體驗的事情都可以做。至於內部實現，可以在介面那裡封裝一下，把一個請求分為幾個子請求。比如帖子內容返回除了幾個評論以外，可能還需要返回廣告。可以做成3個子請求，但是ajax應該用一次。

首先非大神，同新手。

這個主要是看你自己的實際情況

分開有分開的好處，比如帖子一次ajax，每條評論一個ajax，這樣用戶等待的時間就會比較短，他首次進頁面等待很短的時間就能看到頁面上有內容了，但是同樣的原理，你ajax請求多了，代表你http請求就多了，dns查詢，請求http，這些都是耗時操作，在網路不好的情況下會很傷的

合併也有合併的好處，帖子和評論全部一條ajax載入完畢，在網路環境好的情況下用戶幾乎一瞬間就能看到所有的信息（帖子+評論），但是網路情況不好的情況下，用戶可能會等很久才會看到你的內容。

前端頁面的性能在拋卻http請求（包括請求靜態文件）的情況下，主要的阻塞應該就是dom操作了。這個前端優化應該沒什麼區別。

渣渣表示不理解百度等門戶網站的信息究竟是如何處理的，但是應該是分散式+緩存的原理吧（如果有大神明白具體細節並且方便的話可以講一講，小白不勝感激~）

那麼好的問題，忍不住來答一下

我來說一下我的思路，按我們公司的項目來做的話，點文章標題跳轉詳情頁面，頁面初始就呈現的一般選擇後端渲染（其實前端AJAX請求渲染也可以）然後如果像評論是摺疊的默認不展示的話那評論就單獨一個AJAX，如果評論默認展示那麼就展示幾條或者幾十條，做分頁

文章列表頁面，只要傳文章標題、時間、評論數、文章ID等信息就可以了，一樣做分頁處理，跳轉詳情頁面的時候的請求只要傳ID就好了。

分頁我建議是第一次分頁請求請求兩頁的數據，但是只渲染一頁，當用戶點下一頁的時候直接渲染已經請求到的數據，然後在請求之後的一頁。這樣讓用戶感覺會更加快一點。

很有價值的問題，贊一個。

帶著這個問題，可以去看restful api和graphql的區別。如果在嚴格的restful api下，原子化的內容必須經過多次向後台請求，然後完成在前端的拼接，這是沒辦法避免的，（有時候也不是壞事）但保證了後端的簡潔。

graphql生來就是為了解決你提出來的問題。不多解釋了，相關介紹很多。

當然現階段部署graphql的代價還是很高的。作為折中，如果必要，可以和後台商量一個batch api，作為嚴格rest的補充，即一次發送多個資源請求，後台打包發回來，前端再拆解拼裝，這樣可以減少ajax數量。again，大部分時間其實並不必要這麼做。

看來題主是入門前端，終於有不問學那個框架好了。

首先，我覺得這個問題應該是問如何設計合理的RESTful API或者其他風格的API，通常來講，後台不會為某個頁面來寫API而只是為了需求而寫，因為API網頁可以發送請求，手機應用也可以放鬆請求。

對於載入數據，如果數據量很大的話，比如一次返回可能會返回100個人以上的數據，那麼一定要在API中寫Paging，就是說我一次只返回第1-10個人的數據，點擊下一頁或者再次請求，那麼返回第11-20人的數據，否則一下返回過多不論是傳輸還是渲染速度都會有很大影響。這個是知乎一個問題下的Response，也是有Paging。

{is_end: false, totals: 292,…} is_end : false is_start : true next : "http://www.zhihu.com/api/v4/questions/59855528/answers?sort_by=defaultinclude=data%5B%2A%5D.is_normal%2Cis_collapsed%2Ccollapse_reason%2Cis_sticky%2Ccollapsed_by%2Csuggest_edit%2Ccomment_count%2Ccan_comment%2Ccontent%2Ceditable_content%2Cvoteup_count%2Creshipment_settings%2Ccomment_permission%2Cmark_infos%2Ccreated_time%2Cupdated_time%2Crelationship.is_authorized%2Cis_author%2Cvoting%2Cis_thanked%2Cis_nothelp%2Cupvoted_followees%3Bdata%5B%2A%5D.author.follower_count%2Cbadge%5B%3F%28type%3Dbest_answerer%29%5D.topicslimit=3offset=3" previous : "http://www.zhihu.com/api/v4/questions/59855528/answers?sort_by=defaultinclude=data%5B%2A%5D.is_normal%2Cis_collapsed%2Ccollapse_reason%2Cis_sticky%2Ccollapsed_by%2Csuggest_edit%2Ccomment_count%2Ccan_comment%2Ccontent%2Ceditable_content%2Cvoteup_count%2Creshipment_settings%2Ccomment_permission%2Cmark_infos%2Ccreated_time%2Cupdated_time%2Crelationship.is_authorized%2Cis_author%2Cvoting%2Cis_thanked%2Cis_nothelp%2Cupvoted_followees%3Bdata%5B%2A%5D.author.follower_count%2Cbadge%5B%3F%28type%3Dbest_answerer%29%5D.topicslimit=3offset=0" totals : 292

至於優化渲染，什麼For loop，可以用用各種MVVM框架，因為這些框架幫助了我們解決問題，例如渲染，事件監聽啊，都妥妥的，不用自己瞎搞。

至於

3.在第二步中，對每一個帖子使用一次ajax獲取該評論的回復，如果有十個評論，那麼除了要用一次ajax獲取所以評論外，還要用十次的ajax獲取每個評論的回復

我覺得這個還是API設計問題，然後也有如何設計資料庫。有可能不需要再次請求，直接JOIN評論的回復，然後選擇最新5個，這樣一次就能獲得帖子，評論和回復，用戶體驗會更好，不用等待請求。很多網站都有『更多』，一般『更多』會再次請求。

總得來說，前端在API方面基本沒什麼話語權，後端給啥就用啥。

可以抓一下知乎的API設計，個人覺得還是挺好的。

前端請求的數據放在URL參數里，後期擴展等都很方便

正常來說，連接越少越好，所以一般會盡量一次ajax請求全部返回，當然也不絕對，該拆分的請求還是要拆分。按照題設說明的是帖子的評論之類，業務場景的重要程度應該要次一級，而且要做分頁處理，那一般還是會做拆分。

第二個問題么，不存在的，首先要理解ajax一般是非同步的請求，分批請求分塊顯示，頁面主體內容通常第一次就載入好了，用戶已經被主體內容吸引，趁機後續非同步載入些其它數據，不會有明顯感知，有些地方還可以用些小技巧，比如loading動畫之類。

至於貼吧之類的為什麼那麼快，作為新手開發，很多技術點離的還有點遠，在提高的過程中慢慢了解吧。大概描述一些點就是：首頁內容頁一般是靜態化處理，放在CDN上；需要請求的數據，後端也可以做專門的中間層緩存，如squid，varnish或阿里系用的ats之類，響應非常快。