Object.hasOwn能防原型链污染，因其是不依赖原型链的静态方法，直接检查对象自身属性；需在白名单校验、配置访问、序列化前判断等场景优先替换hasOwnProperty。
Object.hasOwn 为什么能防原型链污染
当对象的原型被篡改（比如 Object.prototype.hasOwnProperty = null），所有继承该原型的对象调用 hasOwnProperty 都会报错或返回错误结果，导致权限校验、属性检查等逻辑失效。而 Object.hasOwn 是静态方法，不依赖目标对象的原型链，它直接读取对象自身的属性键，绕过 hasOwnProperty 的原型查找过程。
哪些地方必须立刻替换
以下场景一旦原型被污染就会出问题，应优先用 Object.hasOwn 替代：
- 用户输入字段白名单校验（如
if (obj.hasOwnProperty('username'))） - 配置对象安全访问（如
if (config.hasOwnProperty('timeout'))） - 序列化/反序列化前的键存在性判断
- 框架中对传入对象做“是否含某字段”的运行时检查
兼容性与降级写法
Object.hasOwn 在 Node.js ≥16.9 和现代浏览器（Chrome 93+、Firefox 92+、Safari 15.4+）原生支持；旧环境需降级。注意不要用 Object.prototype.hasOwnProperty.call(obj, key) 降级——它仍受原型污染影响。
安全的降级方案是：
const hasOwn = Object.hasOwn || ((obj, key) => Object.prototype.hasOwnProperty.call(Object(obj), key));
关键点：
-
Object(obj)确保非对象值（如null、undefined）不会报错 - 不直接引用
obj.hasOwnProperty，避免触发污染后的原型方法 - 不能简写为
obj?.hasOwnProperty?.(key)，这在原型被设为null时仍会抛TypeError
常见误用：和 in 操作符混淆
Object.hasOwn(obj, 'x') 和 'x' in obj 行为不同：前者只查自身属性，后者查整个原型链。很多开发者误以为 in 更“安全”，其实它更危险——原型污染后，'toString' in obj 可能意外返回 true，导致逻辑绕过。
正确选择原则：
- 只关心对象自己有没有这个键 → 用
Object.hasOwn - 需要检测原型上是否定义了某个可继承属性 → 才用
in（极少见） - 永远不要用
obj.hasOwnProperty做安全边界判断
原型污染不是理论风险，而是真实出现在 SSRF、模板注入、配置覆盖等漏洞链中的环节。哪怕你的代码现在没被攻击，只要依赖了 hasOwnProperty 且未冻结原型，就等于留了一扇没锁的门。
