一个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了，自己的页面，有很多方法去弹一个提示框。

也不确定我这个分析是完全正确，如果有相似问题的或者技术大佬批评指正～