Object.isExtensible仅用于检测对象是否可扩展，不能主动防范属性膨胀；真正防护需结合Object.preventExtensions设限、Proxy拦截非法新增、关键节点断言校验，并规避误用陷阱。
Object.isExtensible 本身不能主动防范属性膨胀，它只是一个检测工具——就像体温计不能退烧，只能告诉你是否发烧。真正防范“属性膨胀”，关键在于提前设限 + 主动拦截 + 精准监控，而不是依赖 isExtensible 去“发现”问题。
明确边界：在关键对象初始化时立即禁止扩展
属性膨胀往往始于子应用或第三方脚本随意往 shared、window 或配置对象上挂属性。与其等膨胀发生后再检查，不如一开始就封住入口：
- 主应用启动后、任何子应用加载前，对约定的共享对象调用 Object.preventExtensions(shared)；
- 对沙箱中暴露给子应用的全局代理对象（如
microApp），也应在挂载前锁定扩展性； - 避免对 window 或 globalThis 直接 preventExtensions（影响太大），改用封装代理层控制写入逻辑。
主动拦截：用 Proxy 捕获非法新增行为
isExtensible 检测不到“谁在什么时候加了什么”，但 Proxy 可以。对高风险共享对象，不直接暴露原生对象，而是包裹一层代理：
- 在
set拦截器中判断：若属性不存在且目标已不可扩展，就拒绝写入并上报； - 配合白名单机制，只允许预定义字段（如
['token', 'theme']）被动态设置； - 非严格模式下静默失败易被忽略，建议开发环境强制抛错，便于定位源头。
轻量校验：在关键节点用 isExtensible 做一致性断言
isExtensible 的合理用途是“确认防护是否生效”，而非实时监控。适合在以下时机快速校验：
立即学习“前端免费学习笔记（深入）”；
- 子应用 mount 完成后，检查其注入的命名空间对象是否仍可扩展（预期应为 false）；
- 每次跨应用通信（如 postMessage 回调）执行后，验证 shared 对象是否仍处于不可扩展状态；
- 自动化测试中加入断言：
expect(Object.isExtensible(shared)).toBe(false)。
规避陷阱：别把 isExtensible 当防护开关
常见误用会削弱防护效果：
- 仅靠定时轮询
if (!Object.isExtensible(obj)) {...}不解决问题，只是被动记录； - 对已被
seal或freeze的对象，isExtensible同样返回 false，但你可能误以为只是 preventExtensions 生效； - 旧版 Android/iOS 不支持该方法，未做兼容检测会导致脚本中断，需前置判断
typeof Object.isExtensible === 'function'。
不复杂但容易忽略：防范属性膨胀的核心不是“看见膨胀”，而是让膨胀根本加不进去。
