不存在“闭包内部使用 with 导致性能崩塌”的问题——因为严格模式下 with 语句在解析阶段即报 SyntaxError，根本无法执行；真正影响作用域性能的是 eval、new Function、深层原型链访问及过度闭包嵌套。
闭包本身不会“使用 with 语句”——with 在严格模式下语法非法，任何包含 with 的函数在定义时就会抛出 SyntaxError，根本无法进入执行阶段，更谈不上“内部使用”或“作用域链查询性能崩塌”。所以这个问题的前提不成立：你不可能在现代 JavaScript（ES5.1+ 严格模式、所有 ES6+ 模块、主流框架/构建工具默认环境）中写出一个“闭包内部含 with”的合法代码。
为什么你根本写不出这样的代码
JavaScript 引擎在解析阶段就拒绝 with：
- ES5.1 起，严格模式明确禁止 with 语句；
- ES6 模块（.mjs、import/export 场景）默认启用严格模式；
- Vite、Webpack、Rollup 等现代打包器默认启用严格模式；
- Chrome/Firefox/Safari 等主流引擎遇到 with 就直接报
Uncaught SyntaxError: Strict mode code may not include a with statement。
如果你看到类似现象，实际可能是这些情况
所谓“性能崩塌”，往往源于对作用域链的误判。真正可能造成类似症状（变量访问极慢、调试困难、意外屏蔽）的，是以下几种合法但危险的模式：
-
eval + 闭包组合：在闭包内动态执行字符串代码（如
eval("x + y")），会强制引擎放弃 JIT 优化，每次都要重建作用域链； -
深层嵌套 + 频繁访问原型链属性：比如闭包中反复读取
obj.a.b.c.d.e，而obj是继承自长原型链的对象，每次访问都需逐级查找； - 意外创建超长作用域链：多层闭包嵌套（A→B→C→D…）且每层都捕获大量变量，导致标识符解析必须遍历数十个活动对象；
- 历史遗留非严格模式代码：仅在老版 IE 或未设 "use strict" 的全局脚本中，with 才可能存活——但这类环境本身已无 JIT 优化，谈不上“崩塌”，只是本来就慢。
如何快速定位真实瓶颈
不用猜 with，用浏览器开发者工具直击问题：
- 打开 Performance 面板 → 录制一段典型操作 → 查看 “Bottom-Up” 标签页，找耗时高的
Script Evaluation或Function Call； - 点击具体函数，在堆栈中观察是否频繁出现在
eval、new Function或深度嵌套的匿名函数里； - 在 Sources 面板中搜索
eval(、new Function(、.apply(、.call(，这些才是动态作用域的真实推手； - 用
console.time()对比：访问局部变量 vs 访问someObj.nested.propvs 访问window.xxx，差距超过 3 倍就值得优化。
一句话结论
不存在“闭包内部使用 with 导致性能崩塌”这种问题——它连编译都过不去。真要排查作用域相关性能问题，请盯紧 eval、new Function、深层原型访问和过度闭包捕获，它们才是现代 JS 中作用域链变重的常见元凶。
