确保配置单例需构建受控容器：私有构造、私有字段、实例方法收口读写，按环境用Spring/闭包/模块级判空实现唯一性，用===验证内存地址一致，并预留热更新与多源扩展能力。

要确保全局配置变量在项目中真正唯一、可维护且不被意外覆盖，关键不是“只定义一次”，而是构建一个受控的单例容器——它封装实例生命周期、隔离状态、预留扩展能力。

用实例方法代替静态字段暴露配置

直接 public static Config config = new Config() 是危险的：外部可任意赋值、无法加锁、无法埋点、无法替换为远程配置。正确做法是把所有配置读写都收口到实例方法：

• 构造函数私有，禁止 new Config()
• 配置字段设为 private，不暴露 getter/setter 的原始引用（例如返回不可变副本或深拷贝）
• 提供 updateFromMap(Map<String, Object>), reloadFromNacos() 等热更新入口
• 内部用 volatile + double-check 或 Spring @PostConstruct 保证初始化安全

按环境选择初始化时机与方式

不同场景下，“唯一性”的保障机制不同，不能一套代码打天下：

• Java 后端：交给 Spring 容器，声明为 @Component + @Scope("singleton")（默认），利用其自动注入、AOP 增强、@Value 绑定和销毁回调
• 前端浏览器环境：用闭包 + IIFE 实现懒加载，首次调用 getInstance() 才创建，且判断 typeof window !== 'undefined'
• Node.js 或 SSR：避免顶层 new，改用模块级 let instance = null + getInstance() 内部判空，防止 require 缓存失效导致多实例
• 嵌入式 C：用 static 结构体 + 不透明指针（opaque pointer），头文件只声明 handle_t 类型，实现文件才定义 struct，彻底隐藏内部布局

验证唯一性不能靠经验，必须用 === 断言

是否真单例，不看文档、不看注释，只看内存地址是否一致：

• 写两行测试：const a = Config.getInstance(); const b = Config.getInstance(); console.log(a === b); // 必须输出 true
• 在多线程/并行流中验证（如 Java 的 parallelStream）：10 个线程同时调 getInstance().get("timeout")，结果必须全部来自同一实例
• 跨模块导入后验证：A 模块 import { getConfig } from './config'; B 模块同样 import，两次 getConfig() 返回对象仍需 ===
• 热更新后验证：调用 reload() 后再 getInstance()，返回仍是原对象（只是内部状态变了），不是新对象

预留演进路径，避免后期推倒重来

今天只是本地 JSON 配置，明天可能要对接 Nacos、Apollo 或数据库。单例设计必须支持平滑升级：

• 所有配置访问统一走 get(key, defaultValue) 方法，不直接访问字段
• 内部存储从 HashMap 切换为 ConcurrentMap，为并发读写留余地
• 增加 addChangeListener(listener)，便于 UI 层响应配置变更
• 日志记录每次 set 操作的调用栈，快速定位非法修改源头