static 关键字：一个词，四种身份

面试的时候，"请你讲一下 C++ 里 static 关键字的用法"大概是出场率最高的基础题之一。

它看起来简单——你在 C 语言里就见过它。

但 static 这个词在 C++ 里至少有四种完全不同的含义，很多人只能说出一两种，剩下的要么混淆，要么压根没意识到它们之间的区别。我们一个一个来拆，每种含义都用具体的代码来感受。

函数内的 static 变量：只初始化一次

先从最直觉的场景开始。假设你写了一个函数，用来生成一组递增的 ID：

int generateId() {
    int id = 0;
    id++;
    return id;
}

你在 main 里连续调用三次：

int main() {
    std::cout << generateId() << "\n";
    std::cout << generateId() << "\n";
    std::cout << generateId() << "\n";
}

输出是：

1
1
1

每次都是 1。因为 id 是一个普通的局部变量，它住在栈上。每次函数被调用，栈帧被创建，id 被初始化为 0；函数返回，栈帧被销毁，id 就没了。下一次调用，一切从头来过。

现在给 id 加上 static：

int generateId() {
    static int id = 0;
    id++;
    return id;
}

同样调用三次，输出变成了：

1
2
3

static int id = 0; 这一行只在第一次进入函数时执行。之后再调用 generateId()，程序会跳过这行初始化，直接使用上一次留下来的值。

为什么会这样？因为 static 局部变量不住在栈上，它住在程序的静态存储区（static storage）。这块内存在程序启动时就分配好了，直到程序结束才释放。所以即使函数返回了，id 的值还在那里，下次进来还能接着用。

但有一点没变——id 这个名字的作用域仍然是函数内部。出了 generateId() 这个函数，你写 id 编译器不认识。

用一句话总结：static 局部变量的生命周期变长了（跟程序走），但作用域没变（还是函数内部）。

函数内 static 变量的一个经典用途：计数器

既然 static 局部变量能跨调用保持状态，一个很自然的用途就是给函数调用计数。比如你在调试一个递归函数，想知道它到底递归了多少层：

void dfs(int node) {
    static int callCount = 0;
    callCount++;
    std::cout << "dfs called " << callCount << " times\n";

    // ... 递归逻辑 ...
}

不管 dfs 被调用多少次、从哪里调用，callCount 都会忠实地累加。这在调试时非常方便，不需要额外传参数或者维护一个全局变量。

不过要注意，这种写法有一个隐含的问题：callCount 永远不会被重置。如果你的程序需要多次"从头开始"调用 dfs，这个计数器会接着上一轮继续累加。所以它更适合一次性的调试场景，不太适合需要反复重置的生产代码。

函数内 static 变量的另一个经典用途：Meyers' Singleton

这是面试中经常被追问的一个点。假设你的程序需要一个全局唯一的配置对象，你可以这样写：

class Config {
public:
    Config() {
        std::cout << "Config created\n";
        // 从文件或环境变量加载配置...
    }

    std::string getDbHost() const {
        return "localhost";
    }
};

然后用一个函数把它包起来：

Config& getConfig() {
    static Config instance;
    return instance;
}

第一次调用 getConfig() 时，instance 被构造。之后每次调用，都直接返回同一个对象的引用，不会再构造新的。

int main() {
    Config& c1 = getConfig();  // 输出 "Config created"
    Config& c2 = getConfig();  // 没有输出，直接返回同一个对象
    std::cout << (& c1 == &c2) << "\n";  // 输出 1，确实是同一个对象
}

这就是 Scott Meyers 在《Effective C++》里推荐的单例写法，所以叫 Meyers' Singleton。它的好处是简洁，而且天然解决了一个棘手的问题——初始化时机。instance 一定是在第一次被使用时才创建，不会出现"还没准备好就被别人访问"的情况。

函数内 static 变量的线程安全性

如果你用的是 C++11 或更新的标准，有一个重要的保证：函数内 static 变量的初始化是线程安全的。

什么意思？假设两个线程同时第一次调用 getConfig()：

// 线程 A
Config& c1 = getConfig();

// 线程 B（几乎同时）
Config& c2 = getConfig();

编译器会保证 Config 的构造函数只被调用一次。其中一个线程会执行初始化，另一个线程会等待，直到初始化完成后再拿到同一个对象。你不需要自己加锁。

这是 C++11 标准明确规定的（§6.7）。但在 C++11 之前没有这个保证，所以如果你看到老代码里 Meyers' Singleton 外面还包了一层 std::mutex，那不是多此一举，而是在兼容旧标准。

类中的 static 成员变量：所有对象共享一份

到了类里面，static 的含义变了。我们用一个银行账户的例子来感受。

先看没有 static 的情况：

class BankAccount {
public:
    double balance;

    BankAccount(double b) : balance(b) {}
};

每个 BankAccount 对象都有自己的 balance，互不影响：

BankAccount alice(1000.0);
BankAccount bob(2000.0);
std::cout << alice.balance << "\n";  // 1000
std::cout << bob.balance << "\n";    // 2000

这很好理解——每个人有自己的余额。

现在假设银行要收取一个统一的利率，所有账户共用同一个利率值。这个数据不属于某一个账户，它属于"银行账户"这个概念本身。这时候就该用 static：

class BankAccount {
public:
    double balance;
    static double interestRate;

    BankAccount(double b) : balance(b) {}

    double calculateInterest() const {
        return balance * interestRate;
    }
};

interestRate 不住在任何一个 BankAccount 对象里面。不管你创建多少个账户，内存里只有一份 interestRate。

你可以用 sizeof 来验证这一点：

std::cout << sizeof(BankAccount) << "\n";

输出只会是 double 的大小（通常是 8），因为 static 成员不占对象的空间。它存在于静态存储区，跟对象的内存布局无关。

类中 static 成员变量的定义：声明和定义是分开的

上面的代码还不能直接编译通过。类里面写的 static double interestRate; 只是一个声明——它告诉编译器"有这么个东西存在"，但没有给它分配实际的存储空间。

你还需要在某个 .cpp 文件里写一行定义：

// bank_account.cpp
double BankAccount::interestRate = 0.03;

为什么要这样？因为 static 成员变量本质上是一个全局变量，只不过名字被限定在了类的作用域里。全局变量需要在某个编译单元里有且仅有一个定义（One Definition Rule）。如果你把定义写在头文件里，而这个头文件被多个 .cpp 文件 include，链接器就会看到多个定义，然后报错。

这个"声明和定义分离"的规则是很多初学者踩坑的地方。你写了一个类，编译没问题，一链接就报 undefined reference to BankAccount::interestRate——原因就是忘了在 .cpp 文件里写那行定义。

C++17 的 inline static：省掉类外定义

如果你用的是 C++17 或更新的标准，可以用 inline static 来简化：

class BankAccount {
public:
    double balance;
    inline static double interestRate = 0.03;

    BankAccount(double b) : balance(b) {}
};

这样就不需要在 .cpp 文件里再写一行定义了。inline 在这里的意思不是"内联展开函数体"，而是告诉链接器："这个定义可能出现在多个编译单元里，但你只保留一份就好。"

这和 inline 函数的语义是一致的——允许多次定义，链接器去重。C++17 把这个能力扩展到了变量上。

访问 static 成员变量的两种写法

// 写法一：用类名访问（推荐）
std::cout << BankAccount::interestRate << "\n";

// 写法二：用对象访问（能用，但不推荐）
BankAccount alice(1000.0);
std::cout << alice.interestRate << "\n";

两种写法效果完全一样，但第一种更好。因为 static 成员不属于某个对象，用类名访问能让读代码的人一眼看出"这是一个共享的数据，不是 alice 私有的"。用对象访问容易产生误解，以为每个对象有自己的一份。

类中的 static 成员函数：没有 this 指针

理解了 static 成员变量之后，static 成员函数就很自然了。

普通成员函数有一个隐藏的参数 this，指向调用它的那个对象。你写 alice.calculateInterest() 的时候，编译器实际上传了一个 this = &alice 进去，所以函数内部访问 balance 其实是 this->balance。

但 static 成员函数没有 this。它不绑定任何对象，所以也不能访问任何非 static 的成员。

来看一个具体的例子。假设银行要提供一个方法来调整利率：

class BankAccount {
public:
    double balance;
    inline static double interestRate = 0.03;

    BankAccount(double b) : balance(b) {}

    // 普通成员函数：有 this，能访问 balance
    double calculateInterest() const {
        return balance * interestRate;
    }

    // 静态成员函数：没有 this，只能访问 static 成员
    static void setInterestRate(double newRate) {
        interestRate = newRate;
    }
};

setInterestRate 是一个 static 函数。它可以访问 interestRate，因为 interestRate 也是 static 的，不需要通过某个对象来找到它。

但如果你在 static 函数里试图访问 balance：

static void setInterestRate(double newRate) {
    interestRate = newRate;
    // balance = 0;  // 编译错误！
}

编译器会报错。道理很直接：balance 每个对象一份，alice 有 alice 的 balance，bob 有 bob 的 balance。你在一个没有 this 的函数里说"我要访问 balance"——哪个对象的 balance？编译器不知道，所以拒绝编译。

调用 static 成员函数也是两种写法：

// 推荐：用类名调用
BankAccount::setInterestRate(0.05);

// 也行，但不推荐
BankAccount alice(1000.0);
alice.setInterestRate(0.05);

同样的道理，用类名调用更清晰，因为这个操作跟 alice 这个具体对象没有任何关系。

面试追问：static 成员函数能不能是虚函数？

这是一个高频追问。答案是不能。

要理解为什么，需要知道虚函数是怎么工作的。当你调用一个虚函数时，程序会通过对象内部的虚函数表指针（vptr）去查虚函数表（vtable），找到实际应该调用的函数版本。这个过程的起点是 this 指针——没有 this，就找不到 vptr，就查不了 vtable。

而 static 函数恰恰没有 this。所以 static 和 virtual 是天然互斥的。

如果你在代码里写 static virtual void foo();，编译器会直接报错。

静态对象的析构时机

这个知识点面试偶尔会考，通常以"看代码说输出"的形式出现。我们用一个带构造和析构输出的类来观察。

先定义一个简单的类：

class Guard {
    std::string name;
public:
    Guard(const std::string& n) : name(n) {
        std::cout << name << " constructed\n";
    }
    ~Guard() {
        std::cout << name << " destroyed\n";
    }
};

先看普通局部对象的行为：

void test() {
    Guard g("local");
    std::cout << "inside test()\n";
}

int main() {
    test();
    std::cout << "back in main()\n";
}

输出：

local constructed
inside test()
local destroyed
back in main()

g 是 test() 的局部变量，函数返回时就析构了。所以 "local destroyed" 出现在 "back in main()" 之前。

现在给 g 加上 static：

void test() {
    static Guard g("static-local");
    std::cout << "inside test()\n";
}

int main() {
    test();
    std::cout << "back in main()\n";
}

输出变成：

static-local constructed
inside test()
back in main()
static-local destroyed

static 对象的析构被推迟到了程序结束时（main 返回之后）。即使 test() 函数早就返回了，g 这个对象还活着。它的名字出了 test() 就不可见了，但对象本身一直存在，直到程序退出才调用析构函数。

再来一个稍微复杂的例子，看看多个 static 对象的析构顺序：

void foo() {
    static Guard a("A");
}

void bar() {
    static Guard b("B");
}

int main() {
    foo();
    bar();
    foo();  // 第二次调用，A 不会再构造
    std::cout << "end of main\n";
}

输出：

A constructed
B constructed
end of main
B destroyed
A destroyed

注意两个细节。第一，foo() 被调用了两次，但 A 只构造了一次——第二次调用时 static Guard a("A"); 被跳过了。第二，析构顺序是 B 先于 A，和构造顺序相反。这是 C++ 的规则：static 局部对象按照它们被构造的顺序的逆序来析构，保证后构造的先销毁。

文件作用域的 static：限制链接属性

这是 static 最容易被忽略的一个用法，也是从 C 语言继承过来的。

当你在函数外部（也就是全局作用域）定义一个变量或函数时，它默认具有外部链接（external linkage），意味着其他编译单元（其他 .cpp 文件）可以通过 extern 声明来访问它。

来看一个具体的例子。假设你有两个源文件：

// utils.cpp
int helperValue = 42;

int square(int x) {
    return x * x;
}

// main.cpp
#include <iostream>

extern int helperValue;
extern int square(int x);

int main() {
    std::cout << helperValue << "\n";   // 42
    std::cout << square(5) << "\n";     // 25
}

两个文件分别编译，链接时 main.cpp 能找到 utils.cpp 里定义的 helperValue 和 square，因为它们默认具有外部链接。

现在给它们加上 static：

// utils.cpp
static int helperValue = 42;

static int square(int x) {
    return x * x;
}

再编译链接，main.cpp 就会报错：undefined reference to 'helperValue' 和 undefined reference to 'square'。

static 把它们的链接属性从"外部"改成了"内部"（internal linkage）。它们现在只属于 utils.cpp 这个编译单元，对外完全不可见。

文件作用域 static 的用途

这个特性的核心用途是隐藏实现细节。

假设你在 utils.cpp 里写了一些辅助函数，它们只是内部实现的一部分，不想暴露给其他文件。如果不加 static，其他文件可能会意外地 extern 声明并调用它们，导致你以后想修改或删除这些函数时发现有人在依赖它们。

加上 static 就相当于说："这个东西是我的私有实现，你们别碰。"

// image_loader.cpp

// 这个函数只在本文件内部使用，不暴露给外部
static bool isValidFormat(const std::string& filename) {
    return filename.ends_with(".png") || filename.ends_with(".jpg");
}

// 这个函数是对外接口
Image loadImage(const std::string& filename) {
    if (!isValidFormat(filename)) {
        throw std::runtime_error("unsupported format");
    }
    // ... 加载逻辑 ...
}

isValidFormat 加了 static，其他文件看不到它。loadImage 没加，其他文件可以通过头文件声明来调用它。

匿名命名空间：文件作用域 static 的现代替代

在现代 C++ 里，更推荐用匿名命名空间（unnamed namespace）来达到同样的效果：

// image_loader.cpp
namespace {
    bool isValidFormat(const std::string& filename) {
        return filename.ends_with(".png") || filename.ends_with(".jpg");
    }
}

匿名命名空间里的所有东西都自动具有内部链接，效果和 static 一样。

那为什么更推荐匿名命名空间？因为文件作用域的 static 只能用于变量和函数，而匿名命名空间可以包含任何东西——类、枚举、类型别名等等：

namespace {
    // 这些都只在当前文件可见
    enum class Color { Red, Green, Blue };

    struct Point {
        double x, y;
    };

    constexpr int MAX_RETRY = 3;
}

如果你用 static，就没办法给一个 struct 或 enum 加上内部链接。所以匿名命名空间是更通用的方案。

C++ Core Guidelines（C.2）也建议：优先使用匿名命名空间，而不是文件作用域的 static。

四种 static 放在一起看

面试的时候能把这四种清晰地分开讲，基本就过关了。如果还能提到 C++11 的线程安全初始化、C++17 的 inline static、以及匿名命名空间作为文件作用域 static 的替代方案，那就是加分项。

Static Initialization Order Fiasco

最后补一个进阶知识点，面试里偶尔会被问到。

不同编译单元里的全局 static 变量（更准确地说，具有静态存储期的非局部变量），它们的初始化顺序是未定义的。C++ 标准只保证同一个编译单元内的全局变量按照定义顺序初始化，但不同编译单元之间的顺序，编译器可以随意安排。

这会导致什么问题？来看一个例子。假设你有一个全局的注册表，和一个需要在启动时注册自己的模块：

// registry.cpp
std::vector<std::string> registry;

// module_a.cpp
#include <vector>
#include <string>

extern std::vector<std::string> registry;

// 这个全局变量在初始化时会往 registry 里插入一条记录
struct AutoRegister {
    AutoRegister() {
        registry.push_back("module_a");
    }
};

AutoRegister reg;

问题来了：reg 的构造函数会访问 registry，但 registry 此时初始化了吗？

如果 registry.cpp 先于 module_a.cpp 初始化，没问题。但如果反过来，reg 的构造函数在 registry 还没初始化的时候就去调用 push_back——这就是未定义行为，程序可能崩溃。

这就是所谓的 "Static Initialization Order Fiasco"（静态初始化顺序灾难）。

解决办法就是前面提到的 Meyers' Singleton 模式——把全局变量包在函数里，用函数内 static 变量来保证初始化顺序：

// registry.cpp
std::vector<std::string>& getRegistry() {
    static std::vector<std::string> registry;
    return registry;
}

// module_a.cpp
std::vector<std::string>& getRegistry();  // 声明

struct AutoRegister {
    AutoRegister() {
        getRegistry().push_back("module_a");
    }
};

AutoRegister reg;

现在 registry 一定在第一次调用 getRegistry() 时才初始化。不管哪个编译单元先执行，只要你通过函数来访问，就能保证拿到的是一个已经初始化好的对象。

这个技巧的本质是：把"非局部静态变量"转换成"局部静态变量"。非局部的初始化顺序不可控，局部的初始化顺序由调用时机决定——而调用时机是你代码逻辑控制的，所以就可控了。