仅含静态方法的类自动初始化方案是否存在安全隐患？

我在头文件仅存的库中采用如下方式自动初始化一个仅含静态方法、不应被实例化的类：

class Config {
public:
    Config() = delete; 
    static void someMethod_1() {}
    static void someMethod_2() {}
private:
    // 初始化方法
    static bool initialize()
    {
        // 在此执行初始化操作，例如检测处理器核心数...
        ...

        // 完成初始化
        return true;
    }
    // 若干静态inline属性...
    ...

    // 类中最后一个属性，此时其他属性应已完成（默认）初始化
    static inline bool is_initialized = initialize();
};

据我所知该方案的初始化顺序合规，且自C++11起静态初始化保证单线程执行、具备线程安全性，但我是否遗漏了潜在隐患？

你这个方案确实利用了C++11及以后的静态初始化线程安全特性，类内静态成员的初始化顺序也符合声明顺序，内部依赖是合规的，但仍有几个容易忽略的潜在隐患：

• C++版本兼容性限制：static inline静态成员是C17才正式引入的特性，如果项目需要兼容C11或C++14编译器，这段代码会直接编译失败。
• 跨编译单元的初始化依赖风险：如果initialize()中依赖了其他全局对象或非本类的静态成员，这些外部对象的初始化顺序是未定义的。比如initialize()调用了另一个全局类的静态方法，但该类的初始化可能晚于Config，会导致initialize()执行时访问未初始化的对象，触发未定义行为。
• 初始化失败无处理机制：initialize()返回的布尔值仅存在is_initialized中，但没有任何逻辑在调用someMethod_1()/someMethod_2()前检查初始化状态。如果初始化出错（比如硬件信息检测失败、资源分配失败），后续静态方法会在未正确初始化的环境下运行，引发难以排查的问题。
• 资源泄漏风险：如果initialize()中创建了需要手动释放的资源（如动态内存、文件句柄、网络连接），由于Config没有对应的析构或清理逻辑，这些资源会在程序结束时无法被正确释放，造成资源泄漏。静态对象的析构顺序是初始化的逆序，但Config没有析构函数，也没有专门的清理方法，这类资源会一直占用到进程终止。
• 头文件重复包含的编译风险：虽然头文件通常会用#pragma once或包含保护避免重复包含，但如果遗漏这些防护，多个编译单元包含该头文件会导致重复定义错误。另外，initialize()作为类内定义的静态函数默认是inline的，没问题，但如果后续改为类外定义且未加inline，会引发链接错误。

内容的提问来源于stack exchange，提问作者ScratchingTheSurface