@qq_A_32 ? 各有利弊吧，需要看業務本身的需求，我們先說下前端請求：可以被瀏覽器304，組織上更靈活，但是異步請求是會有效率問題的，頭部請求，尾部請求，再或者某個模塊請求，都是會消耗網絡資源，畢竟一個請求的發起，要通過http的三次握手，雖然行的http協議添加諸如keep-alive等功能，提供多路復用，但是支持http的TCP協議建立通道的時候也是會消耗資源。如果我們要求用戶想看到某些模塊，可以通過同步的方式該數據加載進來，不重要的 或者不在首屏的通過@qq_A_32 的方式來進行維護，而且異步維護的話，我們的請求本身就可以，被前端完全控制。