javaScript在浏览器中由js引擎（如V8）执行，不依赖操作系统或外部解释器；遇到标签时默认同步阻塞解析，async/defer改变执行时机；执行分Parse、Compile、Execute三阶段；异步任务通过Event Loop调度，console.log异常多因执行时机或对象引用问题。
javascript 代码在浏览器中运行于 V8（chrome/edge）、SpiderMonkey（firefox）或 JavaScriptCore（safari）等 JS 引擎内部，不是直接由操作系统执行，也不依赖外部解释器。
浏览器加载 html 时如何触发 JS 执行
当浏览器解析 HTML 遇到 标签，会按顺序暂停 dom 构建、下载（如非 async/defer）、编译并立即执行脚本——这是默认的“同步阻塞”行为。
- 内联脚本（
）在解析到该标签时立刻编译+执行 - 外部脚本（
）会发起 http 请求，完成后才进入编译阶段 -
async脚本下载不阻塞 HTML 解析，但下载完立即执行（可能打乱顺序） -
defer脚本下载不阻塞，且统一等到 DOM 解析完成、DOMContentLoaded触发前按顺序执行
JS 引擎执行代码的三个核心阶段
以 V8 为例，一次 eval() 或脚本加载会经历：① Parse（生成 AST）、② Compile（生成字节码或机器码）、③ Execute（在调用栈中运行函数）。
- 顶层代码（非函数体）在编译后立即进入执行阶段，形成第一个
Global Execution Context - 每个函数调用都会新建一个执行上下文，压入
Call Stack；返回时弹出 -
setTimeout、fetch回调等异步任务不会进 Call Stack，而是由 Web API 处理后推入Task Queue，等 JS 主线程空闲再由 Event Loop 拉取执行
为什么 console.log(‘a’) 有时不输出，或输出顺序反常
常见于异步逻辑混用、执行时机误判，比如：
立即学习“Java免费学习笔记（深入）”；
- 在
document.write()后调用console.log()—— 若document.write()清空了文档，后续 JS 可能被中断或重载，日志丢失 - 把
console.log()放在fetch().then()外部，误以为它会等请求结束：实际它立刻执行，而.then()里的日志才在响应后打印 - 使用
console.log(obj)查看对象，但浏览器控制台显示的是“引用快照”，不是打印瞬间的值；应改用console.log(json.stringify(obj))或断点调试
真正决定 JS 是否运行、何时运行、能否访问 DOM 的，是它所处的执行上下文生命周期和浏览器事件循环调度机制。很多看似“JS 不执行”的问题，其实卡在资源加载、跨域限制、CSP 策略或执行上下文尚未就绪上。