关于promise包裹的同步函数的处理问题

Question

大多数情况下，我了解如何在 promise 中包装异步和同步函数，以及这样做的好处和原因。但是，我不明白它们是如何在浏览器中处理的。例如，如果依次调用两个同步函数（两个连续语句），则第二个函数在第一个函数返回之前不会开始。如果每个同步函数都被包装在一个 promise 中，然后一个接一个地调用（不是在另一个then语句中而是在两个连续语句中），那么同步函数现在会并发处理而不是按顺序处理吗？除了对假设场景感兴趣之外，我还有充分的理由进行提问。我正在开发一个可以在单个本地 HTML 页面中打开选项卡式显示的扩展程序。当页面打开时，注入的脚本打开 indexedDB 数据库并启动一组承诺，检索每个选项卡的数据并用适当的数据填充每个选项卡的各个部分。将这些放在 a 中Promise.all给人的印象是所有这些工作都是同时进行的，并在检索数据时填充选项卡，而不是连续填充每个选项卡。在多个单独的 promise（每个选项卡一个 promise）中，当事务完成时，将调用同步函数以在该选项卡的不同部分显示数据。按照现在的编码，用于显示的同步函数在连续语句中一个接一个地调用，这样选项卡的第二个部分仅在第一个完成并返回后填充。因为整个事务已经完成，所有部分的数据已经被检索到；因此，显示的第二个功能不必等待第一个完成。如果这些显示函数被包装在一个 promise 中并被这样调用，选项卡的两个部分是否会同时填充？事务可以被拆分，使得每个选项卡部分有一个事务，并且一旦检索到它们的特定数据，同步显示功能将立即开始；但是，我想为每个标签保留一笔交易。无论哪种方式，加载过程都足够了；但我想了解，即使用户无法察觉，将显示功能包装在 Promise 中是否会导致选项卡中单独部分的并发填充。也许，我只是感到困惑，虽然承诺并Promise.all给人以并发进程的印象，但 JavaScript 中确实没有这样的事情，所发生的一切只是异步函数在它们的事件完成时依次处理。如果是这样，如上所述，在承诺中包装同步函数在加快选项卡部分中的数据填充方面没有任何好处。如果这是正确的，那么提高加载速度的唯一方法就是拆分交易；只有当事务中的一个数据检索步骤比其他步骤花费更长的时间并延迟事务的完成和显示该数据的功能的启动时，这才会有所帮助。对于这个问题的长度，我深表歉意，如果因为没有要审查的代码而被认为不合适，我当然不会删除它。但是，如果您能解释我理解中的错误，我将不胜感激。谢谢你。