服务器端代码如下:
@RequestMapping(value = "/test")
@ResponseBody
public Result test(){
result.setSuccess(true);
result.setData(new Random().nextDouble() + System.currentTimeMillis());
return result;
}
chorme的network截图如下,发现两次请求返回的内容是同一个
请求一
请求二
经过多次试验,发现请求是都走到Controller里,但是第一次请求的响应数据没有马上返回给浏览器端,而是和第二次请求的响应一起返回给了前端,并且第一次请求的响应内容居然是第二次响应的内容。
有时候两次请求的响应能不相同,有时候却相同,不知道是什么原因。
我的实际应用场景是,前台上传多个附件,但是本质是多次上传,然后由后台返回此文件在数据库中的文件id。然后我发现有时上传多个文件时,返回的文件id都是同一个。
如下图所示:两个上传的文件长度是不一样的
文件一
文件二
但是服务器返回的文件id却是一样的:
文件一
文件二
文件一
请求消息
响应消息
文件二
请求消息
响应消息
瀏覽器請求的url後面加上防止快取的時間戳記試試
看了下評論,有可能就是那種情況,你看下回應碼是多少,304的話就跟上次相同。因為請求的url一樣,所以瀏覽器使用的快取數據,你可以在請求中加個隨機參數(時間戳),保證每次的url不一致。
看下spring mvc controller的日誌 看請求到達伺服器的時間是否是同一毫秒
首長你又來了,你試試看用
System.nanoTime()
看看回傳值。由於缺失請求資料等重要資訊(是GET請求還是POST請求?這兩個請求是怎麼發起的?相關的客戶端程式碼是怎麼寫的?),所以以下僅為個人猜測:
1、你這兩個請求幾乎是同時向伺服器發起的;
2、基於1的猜想,
new Random().nextDouble() + System.currentTimeMillis()
幾乎可以認為差值不大(尤其是本地測試的時候);3、你用了double來儲存這個隨機數,然後jackson在序列化double值的話有可能發生精度丟失(關於js的精度丟失問題請自行搜索),所以在客戶端看起來你這兩個值是一模一樣的;
基於1的猜想,假想驗證方法如下:
看一下輸出結果,並且把輸出結果在瀏覽器裡的console裡用JSON.parse(log出來的數值)看一下是否一樣。
解決方法:用字串儲存這個隨機數,以下是我自己寫的一個產生若干位隨機數的方法(java8):
至於你分割線後的問題,沒有程式碼,無法分析。
服務端,把請求的URL路徑參數印到控制台看看,應該兩次請求印到服務端是一模一樣的,所以服務端當一個請求處理掉了。上面的System.nanoTime();方法可以都試試看。