Object.preventExtensions 适合 API 响应防护，因其仅禁止新增字段而保留读写删自由，兼顾防污染与灵活性；应在请求层（如 axios 响应拦截器）立即调用，配合 TypeScript 和严格模式效果更佳。
用 Object.preventExtensions 锁定 API 返回结构，本质是“关上新增字段的门”，但不阻止已有字段的读写或删除——它适合在数据进入业务逻辑前做一层轻量防护，防止因误操作（比如拼错键名、意外赋值）悄悄注入无效字段，干扰后续判断或上报。
为什么 preventExtensions 比 freeze/seal 更合适？
API 响应对象通常需要保持可变性：字段值可能要更新、清理、临时标记；某些字段也可能被有条件删除（如过滤掉空值）。而：
-
Object.freeze会冻结所有属性（不可写、不可配置、不可扩展），导致后续赋值静默失败，调试困难； -
Object.seal允许改值、不允许删字段或加字段，但很多前端逻辑依赖临时删字段（如剔除敏感字段再上报），seal 会拦住这个合理操作； -
preventExtensions只禁新增字段，保留读、写、删的自由，刚好卡在“防污染”和“保灵活”的平衡点上。
在请求响应后立即锁定，越早越好
不要等数据流转到组件或 store 才处理。最佳位置是封装的请求层（如 axios 的 response interceptor 或自定义 hook 内部）：
// 示例：axios 响应拦截器
axios.interceptors.response.use(response => {
const data = response.data;
if (data && typeof data === 'object' && !Array.isArray(data)) {
Object.preventExtensions(data);
}
return response;
});
这样所有经过该请求层的响应对象，从诞生起就无法被意外添加字段。注意：只对 plain object 处理，跳过数组、null、原始值或 Date/RegExp 等内置对象。
配合 TypeScript 使用，效果更稳
preventExtensions 是运行时防护，TypeScript 是编译时约束。两者互补：
- TypeScript 能提示“xxx 属性不存在”，但类型断言（
as any）或//@ts-ignore会绕过； - preventExtensions 在运行时真正拦截非法赋值（严格模式下报错，非严格模式静默失败），堵住 ts 漏网之鱼；
- 建议在开发环境开启严格模式（
"use strict"），让非法扩展直接抛错，便于快速定位问题代码。
警惕常见失效场景
preventExtensions 只作用于目标对象本身，不递归子对象：
- 如果 API 返回嵌套对象（如
{user: {name: 'a'}, tags: [...]}），只锁了顶层，data.user.xxx = 1仍会成功； - 解决方法：递归锁定（谨慎使用，避免性能开销），或只锁定你明确信任的“根结构”，深层对象按需单独处理；
- 注意 Proxy 对象、Map/Set 等非普通对象不受影响，它们本身就不支持 preventExtensions；
- 深克隆后的对象是新对象，未被锁定，需重新调用（若有必要）。
不复杂但容易忽略——加一行 Object.preventExtensions，就能让 API 数据结构多一道防线，尤其在多人协作、逻辑分层复杂的项目里，值得成为标准动作。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
