LUO12826

不知道现在还有没有朋友在学或者纠结这些，正好之前略微研究过，用大白话说下我的理解:

首先谈论这个话题，一定要先分清 JS 语言本身和它的宿主环境（浏览器，Node.js 等等）。

在早期，JS 语言本身（注意是它的本身）是完全没有异步的概念的。可以想象 JS 引擎最主要的作用是提供一个叫 runCode 的函数接口，参数是一段 JS 代码，JS 代码跑完后这个接口就返回。但在交互式的 Web 页面里，显然 JS 引擎不可能只跑一趟就完工了，还有按钮 click 、setTimeout 、网络请求返回等事件会在网站加载后某刻发生。这是怎么做到的呢？其实是浏览器，也就是宿主环境来负责的：当你设置一个按钮回调时，浏览器记录下了按钮对应的回调。用户点按钮时，浏览器调用 JS 引擎的 runCode ，把你写的回调传进去执行一下。setTimeout 也是同理，其实是宿主环境帮你在特定时间把回调扔给 JS 引擎跑。

那万一一个按钮回调和一个定时器同时触发咋办？众所周知 JS 选择了单线程作为心智模型，那必然不能让多个 runCode 同时跑，所以要引入一个队列，让这些 js 代码排着队一个个进 runCode ，一个执行完了（也即 runCode 返回了）再跑下一个。这个队列就是任务队列，也就是有些人口中的“宏队列”。在 JS 引擎眼里，它其实不知道什么是异步，也不知道有任务队列，只知道宿主时不时丢点 js 代码让它跑。

到了 ES6 时代，Promise 进入了 JS 官方规范，JS 语言本身的世界里也出现了异步的概念。Promise 产生的异步任务，按照 JS 世界的惯例，也需要排着队一个个执行。而由于这是 JS 语言本身的设计，JS 引擎责无旁贷，也需要增加一个任务队列，这就是“微队列”。这时候，JS 引擎就不只是把 runCode 传进来的代码执行完就行了，它还得看看这段代码执行后，微队列里是不是有活。如果有，那就得把活干完，再让 runCode 返回。

在八股文中，这一般表述为“宏任务中产生的微任务总是紧跟在这个宏任务之后、下个宏任务之前执行”。

故事基本上就是这样，一些细节由于工程实现的方便或者其它人为规定，可能会有出入。

说真的，好显示器确实难买，强如 studio display XDR 这样的，也普遍反应有边缘发暗且有粗糙感的问题。

会有，电感啸叫，功耗高时可以听到。

@WithoutSugarMiao #41 点了，不知道的还以为本坛人均大厂高管，然而点到酷工作板块咋经常能看到“大专”“13k”“欠薪”这样的关键词呢（仅现象观察）

@Dream4U #33 人已经说了是 8B 的模型，相比现在的在线大模型肯定是智障一般。但可以想象在手机、低功耗设备、机器人这种场景下作为端侧处理简单任务的小模型很有潜力。
想感叹一下，比如 chatGPT 刚上线时，本坛很多人对 AI 写代码嗤之以鼻； cursor 刚上线时，很多分享贴下有人质疑是推广。作为偏技术的论坛，怎么很多人都不会用发展的眼光看问题呢。

V 站这些人真是程序员么，碰到什么新产品都要先看衰一番，就不能先看看人家产品的目标和理念是什么吗。

6P4UzqiqLBVtsbADSUGNDn8y138ZZhKH2V4UBJgFrcGz 谢谢大佬，太强大了