严格模式下无“this 转型禁令”术语，实为禁止原始类型自动包装成对象导致的 this 隐式绑定；非严格模式中原始值调用方法会临时包装、this 指向包装对象，而严格模式下 this 为 undefined，暴露设计漏洞并提升安全性。
严格模式下没有“this 转型禁令”这个术语，它不是标准 JS 规范中的正式概念。你提到的，实际指向的是严格模式对 this 的行为约束——特别是禁止将原始类型（如字符串、数字、布尔值）自动包装为对应对象，从而避免隐式转型带来的 this 指向混乱和安全风险。
为什么原始类型调用会出问题？
在非严格模式下，当你对原始值调用方法时，JS 会临时将其包装成对应对象（比如 "hello".toUpperCase() 中，"hello" 会被包装成 String 实例），此时函数内部的 this 指向这个临时包装对象。这看似无害，但一旦你显式访问 this 或依赖其类型，就可能暴露隐患：
- 临时对象不可持久，无法添加属性或修改行为
- 若函数被抽离单独调用（如
const fn = "abc".charAt; fn(0)），非严格模式下this会退化为全局window，造成污染或意外行为 - 这种自动包装是隐式的、不可控的，属于“马虎模式”的典型缺陷
严格模式如何切断这种隐式转型？
严格模式不改变原始值调用方法的语法有效性（"x".length 依然合法），但它彻底禁止了对原始值执行 this 绑定时的自动装箱。关键表现是：
- 当函数以独立方式调用（非对象点调用），且所在上下文为严格模式时，
this值为undefined，不再 fallback 到window或自动包装对象 - 这意味着：如果某个方法内部写了
console.log(this.constructor)，在严格模式下对原始值调用该方法会直接报错（Cannot read property 'constructor' of undefined），而不是返回一个误导性的String构造器 - 这相当于提前暴露了“本不该让原始值承担对象职责”的设计漏洞
如何真正利用这点提升调用安全性？
不能只靠“开了严格模式就自动安全”，需配合主动防护策略：
-
始终启用严格模式：在脚本顶部或函数首行写
"use strict"，确保所有执行环境统一行为 -
避免原始值方法抽离：不要写
const slice = "abc".slice; slice(0,1)这类代码；如需复用，封装为普通函数或使用箭头函数绑定上下文 -
校验 this 类型（防御性编程）：在可能被误用于原始值的函数开头加判断：
if (typeof this !== 'object' || this === null) throw new TypeError('Method must be called on an object') -
用 Symbol.hasInstance 或 instanceof 配合构造器保护：若你定义了自定义包装类（如
class SafeString { ... }），可通过[Symbol.hasInstance]控制实例识别逻辑，拒绝原始值冒充
一个典型对比示例
以下代码在非严格与严格模式下的差异清晰体现了保护机制：
// 非严格模式
function checkThis() { return this; }
console.log(checkThis.call("hello")); // String {"hello"} ← 自动包装，this 是对象
console.log(checkThis.call(42)); // Number {42}
// 严格模式
"use strict";
function checkThis() { return this; }
console.log(checkThis.call("hello")); // undefined ← 原始值不触发装箱，this 就是 undefined
console.log(checkThis.call(42)); // undefined
这个 undefined 不是缺陷，而是信号：提醒你“这里本就不该由原始值主导上下文”。抓住这个信号，就能把潜在的误用拦截在运行前。
