单例模式的容器化管理是通过统一的“单例容器”（如GlobalContext）托管多个业务全局变量，共享生命周期、支持热更新与集中管控；容器自身为单例，内部用ConcurrentHashMap存储对象，提供线程安全的注册/获取/刷新能力，并兼容Spring与非Spring环境，禁止暴露public static字段。
单例模式的容器化管理，不是把多个单例硬塞进一个类里，而是用一个统一的“单例容器”来托管多个业务相关的全局变量对象，让它们共享生命周期、可热更新、易替换、便于集中管控。
用一个单例容器承载多个业务变量
核心思路是：定义一个单例管理器（如 GlobalContext），它自身是枚举或 DCL 单例，内部用 Map<String, Object> 或专用字段持有多个业务对象（如 Config、Cache、Switch、Counter）。所有业务变量不各自实现单例，而是注册/获取于该容器中。
- 避免每个业务类都写一遍 getInstance()、私有构造、volatile 等模板代码
- 新增一个业务变量只需调用
context.register("userCache", new UserCacheImpl())，无需改类结构 - 便于统一做初始化校验、销毁清理、状态快照等横切逻辑
支持运行时热更新与安全访问
容器不能只当“静态仓库”，要提供线程安全的读写能力。例如：
- 用 ConcurrentHashMap 存储实例，保证 get/register 并发安全
- 为关键变量提供
getAndRefresh(String key, Supplier<T> factory)方法，支持按需重建（如配置变更后刷新缓存） - 对开关类变量（如
feature.enabled）封装isOn("pay_v2")，底层自动监听 Apollo/Nacos 配置变更并更新内存值
与 Spring 容器自然协同
在 Spring 项目中，不必重复造轮子。直接将容器本身声明为 @Component + @Scope("singleton")，再通过 @Autowired 注入各业务 Bean：
- 业务对象由 Spring 托管（支持 @Value、@PostConstruct、AOP、事务等）
- 容器类仅负责“索引”和“调度”，比如：
context.getBean(UserService.class)实际委托给 ApplicationContext - 保留非 Spring 环境兼容性：容器内部可 fallback 到手动 new 实例（如测试或嵌入式场景）
预留扩展点，避免静态污染
禁止在容器内暴露 public static 字段。所有访问必须走实例方法：
- 写法正确：
GlobalContext.getInstance().getConfig().getTimeout() - 写法危险：
GlobalContext.CONFIG.getTimeout()（静态字段绕过容器管控，无法加锁、审计、替换） - 后续若需迁移到分布式配置中心，只需重写
getConfig()方法，调用 NacosConfigService 而非本地 Map，上层业务零修改
