从 HTML 规范来看，关于这个问题最重要的一点是任务源定义 https://html.spec.whatwg.org/multipage/webappapis.html#task-source我们可以在哪里阅读：
根据其源字段，每个任务都被定义为来自特定的任务源。对于每个事件循环，每个任务源必须与特定的任务队列关联。
Note
本质上，任务源在标准中用于分离逻辑上不同类型的任务，用户代理可能希望区分这些任务。用户代理使用任务队列来合并给定事件循环内的任务源。
Example
例如，用户代理可以有一个用于鼠标和按键事件的任务队列（与用户交互任务源关联），以及另一个与所有其他任务源关联的任务队列。然后，利用事件循环处理模型的初始步骤中授予的自由度，它可以在四分之三的时间里让键盘和鼠标事件优先于其他任务，从而保持界面响应，但不会让其他任务队列挨饿。请注意，在此设置中，处理模型仍然强制用户代理永远不会无序地处理来自任何一个任务源的事件。
并且在任务队列定义 https://html.spec.whatwg.org/multipage/webappapis.html#task-queue:
事件循环有一个或多个任务队列。任务队列是一组任务。
总而言之，规范只要求每个事件循环至少有一个任务队列。他们不会详细说明任务队列，而是使用任务来源，用户代理（UA）将链接到任何内容任务队列他们希望以自己认为合适的方式进行，只要每个任务任务源均按顺序执行。
有许多任务来源例如，在 HTML 规范中使用这是通用列表 https://html.spec.whatwg.org/multipage/webappapis.html#generic-task-sources:task-source，但每个规格都可以定义自己的，就像消息接口 https://html.spec.whatwg.org/multipage/web-messaging.html#port-message-queue，其中每个消息端口对象将有自己的任务源！ （意味着 UA 可以映射这些消息中的每一个任务源到不同的任务队列).
获取所有的详细列表任务来源这实际上是不可能的，也不是很有用，因为它们实际上可能都以相同且唯一的方式结束任务队列.
我们需要查看的规格的另一个非常重要的部分是事件循环处理模型 https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model:event-loop.
该算法定义了事件循环在每次迭代时应经历的所有步骤。
乍一看有点复杂，而且随着时间的推移，它并没有变得简单，因为越来越多的上下文都遵循这个模型，需要处理非常不同的问题（看着你在 Worker 中的 OffscreenCanvas...).
但是，对于我们在这里感兴趣的内容，让我们假设它很简单并且我们处于 Window 上下文中。
第一步 https://html.spec.whatwg.org/multipage/webappapis.html#step1任务优先级是由规范设计的：
Let 任务队列是事件循环的任务队列之一，以实现定义的方式选择[...]
就在这里，他们对 UA 说，他们有权选择任务队列从中选择下一个任务。这意味着，例如，如果他们有专门的任务队列为了用户交互任务源，另一个只是为了网络任务源，并且两者都包含等待的任务，那么他们可以自由选择他们喜欢先运行的任务。
Now regarding the rendering, if we look how the processing model goes after this task is executed, all microtasks are too and a bunch of measurements are made, we see that at step 11, they should update the rendering https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering. That's actually part of all event loop's iterations (in a Window context), but the first steps of this algorithm is to define if this was indeed a rendering frame or not, meaning that most of the time it will just early exit without doing anything.
When it is a rendering frame though, it has to perform all the rendering steps, as part of the event loop iteration, i.e maybe after a normal task has been executed.
So from the specs point of view, we can't really talk about prioritization here, it's just one part of every event loop iteration, just like the microtask checkpoint, it doesn't go back to the step 1 where they can pick what task to execute, they are forced to execute that part of the event loop. Though technically, in the rendering steps the UA is also the one responsible to determine when it has a "rendering opportunity", so if they want, they can actually set up that prioritization.
所以对于我们网络作者来说，这意味着是的，我们可以拥有requestAnimationFrame在 a 之前回调触发setTimeout(fn, 0)一项（或任何其他任务），至少在调用此任务的一项任务的情况下requestAnimationFrame()方法本身在 a 的开头执行渲染帧.
这实际上可能经常发生，这里有一个小片段，应该可以使它在 Firefox 中非常可靠地发生，有时在 Chrome 中：
/*
In latest FF and Chrome browsers, UI events like mousemove are being throttled by the UA.
(as recommended by the specs)
They make the limit rate match the one of the screen-refresh, like resize or scroll events.
However, at least in Firefox they don't make it part of the 'update the rendering' algorithm,
but execute it as a normal task.
So a 'mousemove' event in this browser actually gives us accesss to the first step of a 'rendering frame'.
This simple snippet tries to demonstrate that,
if successful, "rAF" should always be logged first.
*/
onmousemove = (evt) => {
console.clear();
setTimeout( () => console.log( 'timeout' ), 0 );
requestAnimationFrame( () => console.log( 'rAF' ) );
};
move your mouse over the frame
现在我们可以回答您的所有观点：
1) 渲染回调被赋予最高优先级。
这是真的吗？
正如我们刚刚演示的那样，事实并非如此，即使渲染回调可能会在与调度它们的任务相同的事件循环迭代中执行，我们也不能在这里真正讨论优先级。
2）渲染队列是否作为单独的队列存在，或者是渲染回调的别名？
规格，不要定义任何特殊的任务队列，但是没有任务源用于渲染。这更新渲染图 https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering算法是由许多要执行的不同任务组成的，其中存在运行动画帧回调 https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model:run-the-animation-frame-callbacks-2命令，您可能指的是。但这些回调存储在 Map 中，而不是队列中。
3）渲染哪些回调？当我进行任何重绘时，都会进行渲染回调
一切都在更新渲染图 https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering，但您可能想关注之后发生的事情step 5，因为之前只是一些检查。
4）是否还有其他类型的队列？如果有，我可以在哪里阅读有关它们的信息？
正如已经说过的，规格并没有定义任务队列, and 任务来源定义过于松散，无法给出完整的列表。
但请记住，所有这些都是从规格的角度来看的。实施者可能在很多方面偏离该模型，并且该模型本身足够宽松，可以允许一大堆不同的设置。
作为一个例子，我想向您指出火狐浏览器问题 https://bugzilla.mozilla.org/show_bug.cgi?id=1270059，其中介绍了一个非常有趣的案例：
他们想要拥有setTimeout回调的优先级低于其他任务，但仅在页面加载时。为此，他们确实创建了一个新的任务队列，专门用于这种情况。
现在，在火狐浏览器中, setTimeout回调的优先级低于其他任务，但仅在页面加载时：
function test() {
setTimeout( () => console.log('timeout'));
onmessage = (evt) => console.log('message');
postMessage('', '*');
}
console.log('at page load');
test();
setTimeout( () => {
console.log('after page load');
test();
}, 1000 );
/* results in Firefox:
at page load
message
timeout
after page load
timeout
message
Chrome will always print "message" first, but because they have a 2ms min timeout on setTimeout
*/
另一件需要注意的事情是可能即将到来的优先postTask API https://github.com/WICG/main-thread-scheduling/blob/master/PrioritizedPostTask.md，我们已经可以在 Chrome 中使用它了#enable-experimental-web-platform-features标志，并且暴露了scheduler.postTask(fn, priority)方法，它允许我们控制任务的优先级。
