一個alert引發的血案

最近在做一個關于page office的相關項目，在打開PO框之後，各種操作被限制，被迫用回原生js的相關操作，比如提示用上了alert～

情形描述：alert提示後，關閉PO框，在關閉的時候會觸發鈎子beforeBrowerClosed，在這個鈎子裡面會去調用釋放相關的文檔鎖。但是經常性的，這個鎖釋放的接口沒有被調用到。在沒有alert操作的相關關閉PO視窗的操作則調用正常。

解決方案：将釋放鎖的這個操作在alert之前，并将alert的操作放到setTimeout操作中，確定釋放接口有足夠的時間被調用。

分析：中間有嘗試，将解鎖操作放到alert之前，但是也沒有很大改進，在加了setTimeout之後，情況才有很大改觀。

js是單線程，但單線程永遠會面臨着一個問題，那就是某一段代碼阻塞會導緻後續所有的任務都延遲。又由于 JavaScript 經常需要操作頁面 DOM 和發送 HTTP 請求，這些 I/O 操作耗時一般都比較長。從代碼執行到彈出alert框之間發生了什麼很難确定，取決于當時的時機，是以可能關閉PO框的操作到了一半，alert被中斷了，由于這又涉及HTTP請求，就直接被挂斷。alert彈出之後點選确認之後，回來之後，也不會再重複執行了。

在alert之前放解鎖操作同理，alert之前請求可能發出，但中途被alert挂斷，同樣起不到想要的功能。是以加上setTimeout操作之後，確定HTTP能夠完整執行，不會被挂斷。才能達到想要的效果。

後續優化，可以把alert操作，在確定解鎖正确傳回之後再出發，單個或者多個使用promise.all等。可以確定alert不會挂斷相關操作。或者将alert的提示放蕩PO關閉之後去做，這時就不需要用alert了，自己的頁面，有很多方法去彈一個提示框。

也不确定我這個分析是完全正确，如果有相似問題的或者技術大佬批評指正～