单纯调用 object.freeze(config) 无法真正锁定业务配置文件，因它仅冻结顶层属性，嵌套的 api、features、timeout 等对象内部仍可被修改；必须使用 deepfreeze 递归冻结所有嵌套结构，并在配置完全构造后、任何模块访问前执行。
单纯调用 Object.freeze(config) 无法真正锁定业务配置文件。它只冻结顶层属性，嵌套的 api、features、timeout 等对象内部仍可被随意修改，属于“表面安全”。要彻底防篡改，必须递归冻结所有嵌套结构，并在正确时机执行。
为什么浅冻结根本不够用
业务配置通常不是扁平结构，而是多层嵌套：
-
config.api.baseUrl可被重写，哪怕config已 freeze -
config.features.toggle = true依然生效，因为features对象本身没被冻结 - 数组如
config.whitelist被 freeze 后，push、pop失败，但whitelist[0].id = 999仍可执行 - 非严格模式下，误改操作静默失败，问题难以发现；严格模式则直接抛错，影响运行稳定性
必须用 deepFreeze 递归冻结所有引用值
手动实现一个健壮的深冻结函数，覆盖常规配置中的所有情况：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 只对 plain object 和 array 递归处理，跳过
null、原始类型（string/number/boolean）、函数、Date、RegExp等——这些本就不该出现在纯配置中 - 用
Object.getOwnPropertyNames()遍历所有自有属性名（不含 Symbol），确保不遗漏 - 先冻结子对象，再冻结父对象，保证引用链完整锁定
- 示例代码：
if (obj == null || typeof obj !== 'object') return obj;
if (Object.isFrozen(obj)) return obj;
Object.getOwnPropertyNames(obj).forEach(prop => {
if (obj[prop] !== null && typeof obj[prop] === 'object') {
deepFreeze(obj[prop]);
}
});
return Object.freeze(obj);
}
冻结必须发生在配置完全构造后、任何模块访问前
时机错误会让冻结失效：
- Node.js：在入口文件（如
index.js）最顶部加载配置并立即deepFreeze，再require其他模块 - 浏览器 ESM：在
import './config.js'后立刻调用deepFreeze，不能依赖导出时冻结（打包器可能优化掉） - 禁止在配置对象上提前注入 getter/setter 或 Proxy，否则会干扰 freeze 行为
- 避免模块缓存未冻结版本：比如
const cfg = require('./config')发生在 freeze 之前，其他模块拿到的就是可变引用
额外加固：切断原型链 + 静态检测
即使深冻结，仍有边缘绕过方式：
- 用
Object.setPrototypeOf(config, null)在 freeze 前切断原型链，防止通过config.__proto__.xxx = 1污染 - 配合 ESLint 规则：
no-param-reassign和no-const-assign，提前拦截开发阶段的误赋值 - 上线前加断言：
console.assert(Object.isFrozen(config), '配置未冻结！')，快速暴露疏漏 - 注意：
Object.assign(config, ...)在冻结后自动跳过所有属性，不会报错也不会生效，是安全的
