Noodle 0.9.0 预请求脚本：发送前跑一段 QuickJS，TUI 与自动化走同一条路径

文档：

静态请求字段不够用的时候，Noodle 0.9.0 加了一层很小的脚本面：内联 pre-request 脚本。它可以准备请求、派生签名，或者在后继请求之间传递一次性值——而不用为 TUI 和自动化另造第二条执行路径。

时机：目录覆盖与环境变量替换之后，HTTP 发送之前

脚本不是替代表达式插值，而是排在它后面。请求先合并目录覆盖（folder overrides），再做一次变量替换，然后才轮到脚本执行。也就是说脚本里看到的是替换完成的最终值，写回去的字段会直接进入实际发送的请求。

TUI 与自动化共用同一序列

request run、collection run 和 TUI Runner 执行顺序一致：

1. 合并目录覆盖
2. 替换一次
3. 跑 pre-request 脚本
4. 发送
5. 捕获
6. 断言

同一份 collection 在交互界面和 CI 里跑，脚本行为一致，不存在「TUI 里对、自动化里不对」的分叉。

隔离：每个脚本一个全新的同步 QuickJS runtime

每个脚本拿到的是一个全新的 QuickJS runtime 与 context，脚本之间不共享状态。可用的全局只有：

• request
• env
• run
• crypto
• console（输出会被捕获）

不提供的东西同样明确：Bun、process、文件系统、shell、网络、定时器、worker、模块加载、Promises，以及任何排队的异步工作。脚本是同步的——没有 await，也没有回调式异步。

固定上限

执行时间、运行时内存、栈、源码长度、值大小、JSON 深度、随机字节数和 console 输出量都有硬上限。超出即失败，不会静默降级。

这类嵌入式运行时最容易出问题的地方是构建产物：本地构建和每一个发布目标都会跑一遍编译二进制的冒烟检查，确认用户拿到的东西里脚本运行时确实可用。

请求 tag 的显示

请求 tag 现在以带 # 前缀的强调徽章显示，出现在请求设置和 collection Runner 里。

示例 collection

仓库里带了一个示例 collection，包含两个已审计的 pre-request 脚本：

• 一个给 GET 请求加时间戳和 SHA-256 摘要；
• 一个给 JSON POST 请求加随机 request ID 和一次性 run 值。

两个脚本都用到了上面那组受限全局，没有引入外部依赖。

参考

• Collection format reference：完整的脚本 API 与限制说明。
• Automation：collection-run 的输出格式与失败行为。