浏览器控制台代码与script标签脚本执行环境独立：控制台代码即时在当前上下文中运行，不等待dom；script则按html解析规则调度，受async/defer等属性影响，二者互不阻塞、不共享作用域。
浏览器控制台执行的代码，和页面中 script 标签里的脚本，根本不在同一个执行队列里，也不会相互阻塞或等待——它们是两条平行线。 控制台输入并回车的代码，是即时在当前 JavaScript 执行上下文中求值运行的；而 script 标签里的代码，由 HTML 解析器按规则调度：是否下载、何时解析、在哪一阶段执行，全看它有没有 async、defer，或干脆就放在 里同步堵路。
控制台代码不等 DOM 就能跑，但可能拿不到元素
你在控制台敲 document.getElementById('main') 并回车，浏览器立刻执行——不管此时 HTML 解析到哪了。如果页面还没加载完，或者 <div id="main"> 还没出现在 DOM 树里，结果就是 <code>null。这不是报错，是事实：你查了一个还不存在的东西。
这和 script 标签的行为形成对比：
- 同步脚本（无属性）在 里执行时， 都没开始解析，getElementById 必然为 null；
- 而你在控制台同一时刻敲同样的代码，结果也一样——不是因为“被 script 影响”，而是因为 DOM 确实还没建好。
script 标签里的代码不会“看到”控制台刚定义的变量
控制台执行的代码，是在全局作用域（window）上直接运行的，变量会挂到 window 上（比如你输 let foo = 123，实际等价于 window.foo = 123）。但 script 标签里的代码，尤其是用 let / const 声明的，是块级作用域，不会自动暴露给控制台；反过来，控制台定义的变量虽然在 window 上，但 script 内部若用了严格模式或模块环境（type="module"），foo 就不一定能直接访问。
更关键的是时间差：
- 你先在控制台输 var utils = { log: console.log };；
- 然后刷新页面，再运行一个 <script>utils.log('hi');</script> —— 这会报 ReferenceError，因为控制台的那次执行只存在于上一次页面会话里，刷新后全部清空。
动态插入的 script 和控制台操作容易“抢跑”
用 document.createElement('script') 插入脚本时，现代浏览器默认把它当作 async=true 处理：下载不阻塞，但下载完立刻执行。这时候如果你在控制台紧接着输 window.MyLib?.init()，大概率得到 undefined——不是控制台慢，是脚本还没下载完，或者刚下载完但还没执行到 init 定义那行。
要可靠联动，得主动等：
- 不依赖 onload 就调用，而是检查 typeof window.MyLib === 'object'；
- 或者把控制台操作封装成函数，等几毫秒再重试（简单场景可用）；
- 更稳妥的是让脚本自己触发一个自定义事件，控制台监听它。
模块脚本（type="module"）和控制台几乎“隔绝”
带 type="module" 的 script 是严格隔离的：它的顶层 const/let 不挂 window，也不受控制台声明影响。你在控制台输 import('./utils.js') 是合法的，但输 MyModule.doStuff() 就会报错——除非它明确导出并赋值给了 window。
这种设计不是冲突，而是保护：模块系统靠静态分析依赖，不能被运行时随意污染。所以别指望在控制台“补丁式”改模块行为；真要调试，用 debugger 或 Sources 面板打断点更靠谱。
