v8预解析不生成汇编代码，仅进行函数边界扫描与语法校验；它在字节码生成前以轻量方式识别函数签名和作用域标记，全程不构建ast、不触发编译器后端，是纯前端语法层优化。
V8 并不直接将 JavaScript 编译为汇编指令，也不在冷启动阶段暴露或生成用户可读的 x86/ARM 汇编代码。所谓“通过汇编指令理解函数声明的预解析”，本质上是一种误解——V8 的预解析（Pre-parsing）是纯前端的语法层处理，不涉及任何汇编生成、寄存器分配或机器码落地。它发生在字节码生成之前，且全程在 C++ 解析器内部以 AST-like 结构（但非完整 AST）完成。
真正能观察到的底层行为，是 V8 内部解析器对函数边界和作用域信息的轻量识别，而非汇编层面的指令流。下面从三个实际可验证的层面讲清楚：
预解析不产生汇编，只做边界扫描与语法合法性校验
预解析器（PreParser）的核心任务是：
- 快速跳过函数体内容，仅扫描
function关键字、参数列表、左大括号位置； - 检查是否符合基本语法规则（如括号匹配、无非法 token）；
- 提前记录函数名、形参个数、是否含
await/yield等影响后续编译路径的标记； - 不构建 AST 节点，不生成字节码，更不会触发 Ignition 或 TurboFan 的任何汇编相关流程。
例如：
function foo(a, b) {
return a + b;
}
function bar() {
eval("x = 1"); // 预解析会标记为 "unstable scope"，后续必走 full parse
}
V8 在冷启动时对这两者都只做预解析：foo 被记下签名；bar 因含 eval 被打标，但函数体内容一字未读。
冷启动阶段看不到汇编，但可通过 d8 + --print-bytecode 观察字节码生成时机
真正生成可类比“汇编”的字节码（Bytecode），要等到函数首次被调用（lazy compilation）。此时才启用完整解析器（Parser），构建 AST，并交由 Ignition 生成字节码。
验证方式（使用 V8 命令行工具 d8）：
echo 'function f(){return 42;} console.log("ready")' > test.js
d8 --print-bytecode test.js
输出中不会出现 f 的字节码，只打印 console.log 相关字节码 —— 因为 f 未被调用，仍处于预解析状态。
通过聊天（Telegram / 飞书）执行本地 `clawusage` 监控命令。当用户输入 `/clawusage ...`，或提出“查看 Codex 用量”、“开启/关闭自动…”等请求时触发使用。
加上调用后再试：
echo 'function f(){return 42;} f(); console.log("ready")' > test.js
d8 --print-bytecode test.js
这次输出里会出现 f 的完整字节码序列（如 LdaSmi [42]、Return），这才是真正“落地”的低阶指令，接近传统汇编语义，但仍是平台无关的字节码。
函数声明提升（hoisting）是预解析的副产品，不是汇编重排
JS 中 function foo() {} 能在声明前调用，常被误认为“编译器把函数挪到了顶部”。实际机制是：
- 预解析阶段已识别出所有顶层
function声明，并将它们的名称和签名注册进当前作用域的「函数绑定表」； - 运行时执行上下文创建时，这些绑定已就位，无需等待函数体解析；
- 这一步完全在解析器 C++ 代码中完成，没有指令移动，也没有汇编重排。
对比函数表达式：
console.log(typeof bar); // "undefined"
var bar = function() {};
bar 是变量声明，预解析只处理 var bar;，赋值语句 = function(){} 属于执行期行为，不参与预解析作用域注册。
所以，“通过汇编理解预解析”这条路走不通。真正有效的路径是：
- 用
--print-parse-stack查看解析深度； - 用
--trace-preparse观察预解析日志； - 用
--print-bytecode对比调用前后字节码差异； - 阅读 V8 源码中
src/parsing/preparser.cc的PreParser::ParseFunctionLiteral实现。
预解析是 V8 为速度妥协的轻量语法快照，不是编译流水线的低阶环节。它不生成指令，也不操作寄存器——它只是让 V8 在打开网页的头几毫秒里，少做很多事。
