這個問題本胖有發言權，我這一年做的都是關於購物商城的。其中就有從購物車或商品詳情頁到確認訂單頁面。我是根據確認訂單頁面的資料格式從購物車組織資料（通常最後是搞成一個對象）然後存在localstorage裡面（做的都是行動端），然後直接跳頁面，去確認訂單頁面遍歷渲染那個資料對象就好了，放心，前端這些只是給用戶看的，後台在付錢的時候還會再算一遍訂單金額，再拆單的，所以就算用戶改了支付信息，他還是要付那些錢的，

不是，購物車內容不是由表單傳到服務端的，看你們商城購物車是如何實現的
是放SESSION 還是MySQL,還是redis等等
在訂單提交的時候，購物車內容需要在服務端,
這裡是直接讀庫或SESSION，redis
再次驗證並提交的時候是否一致sku 數量
再重新計算一邊總價格，優惠，總價

最後:永遠不要相信表單提交的數據,含商品價格
否則會鬧出一分錢，買幾千元的笑話來.

和你們後台協商、

我們之前有種做法是、根據後端提供的資料結構、整合成字串、傳給後端、後端根據自己的演算法解析

例如1_xxx_24:2_xxx_56

這種就是後台根據冒號拆分成多個商品、然後根據底線拿到三個參數的值、當時的數據是、參數順序不能錯、參數必須都有、

只是舉個例子、具體的看你們後台想怎麼實現、前台只負責傳和收

把購物車中的資料前端自己存起來，例如VUE裡面的vuex ,react裡面的redux,這些資料會一直存在一個公用的地方，如果沒有登錄，也沒關係，購物車讓他先選，點擊支付了再登錄，最後以一個json數組的形式提交過去