go test -bench在vscode集成终端中输出0 ns/op，根本原因是终端未正确继承环境或模块路径识别错误，需用go test -bench=. -benchmem -count=1 -benchtime=1x强制单次运行并右键测试文件选择go: test package确保工作区正确。
装完 Node.js 和 VSCode 后直接压测，大概率测不准、结果不可复现，甚至根本跑不起来。核心问题不在工具链本身，而在环境一致性、运行模式和 VSCode 的调试/终端行为干扰。
go test -bench 在集成终端里为什么总输出 0 ns/op
这不是代码问题，而是 VSCode 集成终端默认继承了错误的模块上下文或缓存状态。
-
go test -bench=.必须在含*_test.go文件且有合法Benchmark*函数的目录下执行——不是任意目录都能压 - 常见失败现象：
BenchmarkFoo-12 0 0 ns/op，说明函数根本没被调用，大概率是go.mod路径识别错误或模块缓存污染 - 绕过缓存最可靠方式是加参数：
go test -bench=. -benchmem -count=1 -benchtime=1x，强制单次运行，避免优化跳过 - 别信终端当前路径——右键测试文件 → 选择
Go: Test Package，它会自动定位go.mod并设置正确工作区
Node.js 基准测试别只靠 console.time
console.time() 适合粗略验证逻辑耗时，但无法反映 V8 优化行为、GC 影响或真实吞吐压力，压测必须进进程级分析。
- 真正压测要用
node --prof启动，再用node --prof-process解析生成的isolate-*.log - VSCode 调试配置中，
runtimeArgs加--inspect-brk后，必须手动打开chrome://inspect连接，否则 Performance 面板录不到数据 - 如果想测接口吞吐，
console.time+ 循环调用不如直接用autocannon或artillery：它们能控制并发、连接复用和请求节奏，更贴近真实负载 - 注意：VSCode 的“运行”按钮（Ctrl+F5）默认不启用
--prof，必须走launch.json配置或终端手动启
LoadRunner Developer 插件压测前必做的三件事
这个插件不是装上就出 scenarios.json 的，缺一不可，否则命令面板里搜不到 LoadRunner: Initialize。
- 确认 VS Code 版本 ≥
1.80：按Ctrl+Shift+P输入Help: About查看，旧版本直接失效 - 本地必须有
java -version≥ 11 或node -v≥ 16 —— 插件启动时会检查，失败就静默退出 - 安装后必须手动执行一次
LoadRunner: Initialize（在命令面板搜），否则不会生成scenarios.json和results/目录，后续所有压测都无从谈起
vscode-leetcode 插件对性能压测的隐性干扰
它不参与你的压测逻辑，但会在后台持续拉取题目元数据、监听文件路径变化，尤其在大型项目中拖慢终端响应和扩展激活速度。
- 典型表现：打开含 500+ 文件的 TS 工作区后，
Developer: Show Running Extensions里看到vscode-leetcode的Activation Time> 400ms，Runtime Impact标为 Medium - 它无法按语言范围禁用——哪怕你只用它刷题，只要打开
.ts或.js文件，它就激活 - 卸载不等于干净：先点
Uninstall，再删掉settings.json里所有含leetcode的配置项（比如leetcode.problemset），否则 Network 面板仍可能看到 pending 的 leetcode.com 请求
压测结果是否可信，关键不在工具多炫酷，而在于你能否排除 VSCode 自身的环境干扰、确保每次运行条件一致。特别是 go test -bench 和 node --prof 这类底层机制，VSCode 只是壳，真正的执行逻辑全在终端和进程里——别让编辑器的“便利”掩盖了环境的“失真”。
