同步代码阻塞主线程且按书写顺序立即执行，异步代码不阻塞主线程、回调延后执行；典型同步如for循环、console.log，典型异步如settimeout、fetch；输出乱序、依赖回调或await结构可判断异步。
区分 JavaScript 中同步与异步代码的执行顺序，关键看两点：是否阻塞主线程、是否按书写位置立即执行。同步代码严格从上到下逐行运行，前一句没结束，后一句绝不会开始；异步代码虽写在前面，但它的回调或后续逻辑会被推迟到当前同步任务全部完成之后才执行。
看代码是否“等结果”再往下走
同步操作会卡住主线程，直到计算或操作真正完成。比如一个大数组遍历、JSON.parse() 解析长字符串、或直接调用普通函数——这些都属于同步行为，执行完才轮到下一行。
- 典型同步：变量赋值、console.log()、for 循环、if 判断、函数内普通运算
- 典型异步：setTimeout/setInterval、fetch、XMLHttpRequest、Promise 构造器内的操作、addEventListener 绑定的事件处理函数
看输出顺序是否“乱序”
把 console.log 当作探针，观察实际打印顺序，是最直观的判断方式。如果某句 log 出现在它“后面”的语句之后，那它极大概率是异步的。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 写的是：log('A'); setTimeout(() => log('B'), 0); log('C');
- 实际输出：A → C → B（哪怕延时为 0）
- 原因：setTimeout 的回调被推入任务队列，必须等所有同步代码执行完才执行
看有没有“回调”或“链式等待”结构
同步代码返回值可直接使用；异步代码的结果无法立刻拿到，必须通过某种机制“等它回来”：
- 老式写法：传入回调函数，如 fs.readFile(path, callback)
- 现代写法：用 .then() 接 Promise，或用 await 暂停当前 async 函数执行
- 没有这类结构，又涉及网络、定时、用户交互等耗时动作，基本可以判定是异步
注意“伪异步”陷阱
有些代码看起来像异步，实则仍是同步执行：
- Promise.resolve().then(...) 的回调属于微任务，虽不阻塞，但仍属于异步调度，会晚于同步代码但早于 setTimeout（宏任务）
- async function 内部的 await 后面代码，只是暂停该函数，并非阻塞整个线程
- new Promise((resolve) => resolve()).then(...) 立即触发，但执行时机仍在本轮同步任务结束后
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
