javascript单元测试天然兼容严格模式，现代测试环境默认启用，无需手动添加"use strict"，其约束能提升测试可靠性并提前暴露问题。
前端开发中 JavaScript 单元测试本身不“处理”严格模式，而是天然兼容甚至依赖它——因为现代测试环境（如 Jest、Vitest）运行的代码默认就处于严格模式，你无需额外干预，也不该绕过它。
测试文件默认就是严格模式
ES6 模块（.js 文件被 import 加载，或使用 .mjs 后缀）在 Node.js 和浏览器中均默认启用严格模式。Jest 和 Vitest 的测试文件默认按 ES 模块方式解析（尤其在现代配置下），所以：
- 测试代码里写
undeclared = 1会直接报ReferenceError，不是静默挂到全局 - 函数参数重名
function f(a, a) {}在测试文件中会直接导致语法错误，测试根本跑不起来 -
this在普通函数调用中为undefined，和生产环境行为完全一致
不用手动加 "use strict"，但要避免破坏它
你不需要、也不应该在测试文件顶部写 "use strict"——这既冗余，还可能因位置错误失效。更需警惕的是无意中让某段测试脱离严格约束：
- 不要把测试逻辑塞进
eval()或new Function()中，它们在严格模式下作用域隔离更强，变量不会泄露，但也更难调试 - 避免在测试中动态拼接字符串再执行（如
eval('var x = 1')），这类操作在严格模式下无法污染外层，可能导致断言失败但原因难查 - 如果用 CommonJS（
require()）加载被测模块，而该模块本身没启用严格模式，那它内部仍按非严格规则运行——但测试代码自身仍是严格的，边界清晰
严格模式帮你写出更可靠的测试
它的约束实际提升了测试质量：
- 未声明变量立即报错 → 防止测试中误写
exepct（少个 t）却因创建了全局变量而静默通过 -
arguments不再与形参自动同步 → 测试涉及arguments的旧逻辑时，能早发现问题，而不是上线后才崩 - 禁止
with和八进制字面量 → 测试覆盖到这些边缘语法时，能提前暴露不兼容写法 -
this为undefined→ 让你不得不显式绑定上下文（如fn.call(obj)或用箭头函数），测试意图更明确
遇到严格模式报错？别关它，修代码
测试中突然出现 Cannot assign to read only property 或 Delete of an unconfigurable property，说明被测代码或测试辅助逻辑踩了严格模式红线。这时应：
- 检查是否试图给
NaN、undefined或Object.prototype赋值/删除 - 确认是否在测试中用了
delete obj.x，而x是不可配置属性（可通过Object.getOwnPropertyDescriptor验证） - 排查是否在模拟对象时错误地冻结了不该冻的属性（
Object.freeze()后再改会触发严格报错）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
