企业官网建设流程全解析

1. 项目概述：深入C++继承机制的两个“特殊”角落

在C++的面向对象编程世界里，继承机制是我们实现代码复用、构建层次化类体系的核心工具。大多数开发者对继承的基本规则——公有、保护、私有继承，以及派生类对基类成员的访问权限——都了然于胸。然而，当项目规模扩大，设计变得复杂时，我们往往会撞上一些不那么直观的“隐藏规则”。今天，我想和你深入聊聊两个在面试和实际开发中频繁出现，却又容易被误解的继承特性：友元关系的不可继承性与静态成员的共享本质。

你很可能遇到过这样的场景：精心设计了一个基类，并为它声明了友元函数，期望这个“朋友”能同样访问派生类的私有成员，结果编译器却报出“无法访问私有成员”的错误。又或者，你在基类中定义了一个静态成员变量，期望每个派生类都拥有自己独立的一份拷贝，却发现所有派生类对象操作的都是同一个全局变量。这些现象背后，正是C++语言设计者对封装性、内存模型和语义清晰度所做的精妙权衡。理解它们，不仅能帮你避开代码中的“坑”，更能让你从“会用继承”进阶到“懂继承”，写出更健壮、更符合设计意图的C++代码。无论你是正在准备技术面试，还是希望优化现有项目结构，这篇文章都将为你提供清晰的解释和实用的解决方案。

2. 核心概念拆解：友元与静态成员在继承体系中的定位

2.1 友元：打破封装的“特权通行证”及其局限性

在C++中，友元（friend）是一个强大的特性，它允许一个外部函数或另一个类访问本类的私有（private）和保护（protected）成员。这就像给你的好朋友一张进入你家的门禁卡，他可以不通过公开的接口（大门），直接进入你的私人空间（私有成员）。这种设计通常用于重载运算符（如<<,>>）或为某些需要紧密协作的类提供高效的数据访问路径。

然而，友元关系的核心特点是严格的一对一和单向性。当类A声明类B是其友元时，这种“友谊”仅存在于A与B之间。它不会因为类C继承了A，就自动传递给C。从语言设计的角度看，这是为了维护封装的边界。继承体现的是“是一个（is-a）”的关系，而友元体现的是“允许访问（has-access-to）”的关系。如果友元可以继承，那么基类的所有“朋友”都将自动获得访问其所有后代类内部细节的权力，这将导致封装性被严重破坏，类的内部实现细节会不受控制地暴露给一个可能非常庞大的类家族，违背了面向对象设计的基本原则。

2.2 静态成员：属于类本身的“全局”资源

与普通的非静态成员变量（每个对象实例都拥有自己独立的一份拷贝）不同，静态成员是属于类本身的，而不是属于任何一个特定的对象。无论你创建多少个该类的对象，静态成员变量在内存中都只有唯一的一份实例。静态成员函数也是如此，它不能访问类的非静态成员（因为缺少this指针），只能操作静态成员变量。

当静态成员遇上继承时，其行为逻辑与非静态成员有根本区别。派生类继承基类，本质上是继承了基类的成员定义和访问权限。对于非静态成员，每个派生类对象都会获得一份从基类“复制”过来的数据副本。但对于静态成员，派生类继承的不是一份新的拷贝，而是对基类中那个唯一静态实例的访问权。你可以理解为，基类定义了一个全局的、类作用域的资源，而继承机制允许派生类通过自己的类名去引用和修改这个资源。这导致了在整个继承链中，所有类共享同一份静态数据。

3. 友元无法继承：现象、原理与解决方案

3.1 现象复现：为什么“父亲的朋友不是我的朋友”？

让我们通过一个具体的例子来直观感受这个问题。假设我们有一个Person（人）基类，它有一个保护成员_name，并声明了一个全局函数DisplayPerson为其友元，可以打印名字。然后我们派生出一个Student（学生）类，增加了保护成员_stuNum（学号）。

#include <iostream> #include <string> using namespace std; class Student; // 前置声明 class Person { protected: string _name; public: Person(const string& name) : _name(name) {} // 声明友元函数，可以访问Person的私有和保护成员 friend void DisplayPerson(const Person& p); }; class Student : public Person { protected: int _stuNum; public: Student(const string& name, int num) : Person(name), _stuNum(num) {} }; // 友元函数的定义 void DisplayPerson(const Person& p) { cout << "Person's name: " << p._name << endl; // 如果我们尝试在这里访问Student的成员，会怎样？ } int main() { Person p("Alice"); Student s("Bob", 1001); DisplayPerson(p); // 正确：DisplayPerson是Person的友元 // DisplayPerson(s); // 如果取消注释，编译能通过吗？能访问s._stuNum吗？ return 0; }

上面的代码中，DisplayPerson是Person的友元，所以它可以顺利访问Person对象的_name。现在，我们想扩展这个函数，让它也能处理Student对象，打印出名字和学号。一个直觉的想法是：Student是Person，所以把Student对象传给DisplayPerson应该可以，并且因为继承，DisplayPerson作为基类的友元，应该也能访问派生类的成员吧？

我们修改一下函数和调用：

void DisplayPerson(const Person& p) { cout << "Name: " << p._name << endl; // 错误！编译器不知道p实际引用的是Student，即使知道，也无权访问Student的_stuNum // cout << "Student ID: " << p._stuNum << endl; // 编译错误：_stuNum不是Person的成员 } int main() { Student s("Bob", 1001); DisplayPerson(s); // 这里发生了隐式向上转型（upcast），参数是Person& }

即使我们通过DisplayPerson(s)调用，将Student对象向上转型为Person引用传入，在函数内部，编译器视p的类型为const Person&，它根本不知道_stuNum的存在。更重要的是，即使我们通过某种方式（如dynamic_cast）知道了p实际指向一个Student，DisplayPerson函数作为Person的友元，也绝对没有权限访问Student的保护成员_stuNum。这就是“友元不可继承”最直接的表现：友元权限被严格限定在声明它的那个类的作用域内。

3.2 底层原理：编译器视角下的访问控制

从编译器的角度来看，访问控制（public,protected,private）和友元关系都是在编译阶段进行检查的。当编译器解析到DisplayPerson函数体内试图访问p._stuNum时，它会执行以下检查：

1. 查找_stuNum的声明：在当前作用域（函数内）、参数类型Person及其基类中查找。发现Person类中没有_stuNum，因此这是一个未知标识符，直接报错。这一步甚至还没到检查友元关系的阶段。
2. 即使我们通过强制转换((Student&)p)._stuNum告诉编译器这是Student的成员，编译器会进行第二步检查：DisplayPerson函数是否是Student类的友元？检查Student类的定义，发现没有friend void DisplayPerson(...);的声明。因此，访问被拒绝。

关键在于，友元关系不是类的一种属性，不会被子类继承。它更像是编译器在某个类的定义里记录下的一张“白名单”。这张名单只在检查对该类成员的访问时生效。编译器不会去遍历类的继承树，把基类的“白名单”自动合并到派生类的“白名单”里。这样做既是为了效率，更是为了维护清晰的封装边界。

3.3 解决方案：如何让“朋友”认识你的“孩子”？

既然友元关系不能自动传递，如果我们需要一个函数既能访问基类私有成员，又能访问派生类私有成员，正确的做法是什么呢？答案是：在需要访问的每一个类中，分别声明该函数为友元。

我们修改上面的例子，创建一个新的函数Display，它需要同时处理Person和Student：

class Student; // 前置声明 class Person { protected: string _name; public: Person(const string& name) : _name(name) {} // 在基类声明友元 friend void Display(const Person& p, const Student& s); }; class Student : public Person { protected: int _stuNum; public: Student(const string& name, int num) : Person(name), _stuNum(num) {} // 在派生类也声明同一个函数为友元 friend void Display(const Person& p, const Student& s); }; // 友元函数的定义 void Display(const Person& p, const Student& s) { cout << "Person Name: " << p._name << endl; cout << "Student ID: " << s._stuNum << endl; // 现在可以合法访问了 } int main() { Person p("Alice"); Student s("Bob", 1001); Display(p, s); // 正确运行 return 0; }

注意事项与实操心得：

• 明确的需求：不要滥用这种模式。如果一个函数需要成为多个类的友元，首先应该审视设计：这些类之间的耦合是否过高？是否可以通过增加公共接口来减少对友元的依赖？友元破坏了封装，应谨慎使用。
• 前置声明：由于Display函数的参数列表同时包含了Person和Student，而这两个类相互引用（Person的友元声明中用到Student），必须使用前置声明class Student;来打破循环依赖。
• 访问的精确性：注意在Display函数体内，p._name是通过Person的友元身份访问的，s._stuNum是通过Student的友元身份访问的。它们泾渭分明，互不越界。

3.4 更复杂的场景：模板类、内部类与继承友元

C++11标准引入了一个相关特性：继承友元（Friend Inheritance），但它的含义与我们上面讨论的完全不同。它指的是，当一个模板类将其模板参数声明为友元时，该模板参数的所有特化版本都自动成为友元。或者，当派生类将基类声明为友元时，基类可以访问派生类的私有成员（这是一种反向的、特殊的“友元继承”）。这属于更高级的模板元编程技巧，日常开发中较少用到，但了解其存在可以避免概念混淆。

// 示例：模板友元 template <typename T> class Box { T content; public: // 声明模板参数T为友元。对于Box<int>，int是友元？这通常用于T本身是类类型的情况。 // 更常见的用法是 friend T; 但这里仅为说明概念。 friend T; }; class Secret { int secretData; // 假设Secret想访问Box<Secret>的content }; // 此时，在Box<Secret>的特化中，Secret类是它的友元。

对于大多数应用场景，牢记“普通类的友元关系不可继承”这一基本原则就足够了。

4. 静态成员“仅传使用权”：共享的本质与内存模型

4.1 现象验证：全家族共享的“传家宝”

让我们通过代码和内存地址来直观感受静态成员的共享特性。我们创建一个带有静态成员计数器_count的Person类，然后用Student类继承它。

#include <iostream> #include <string> using namespace std; class Person { public: string _name; // 普通成员变量 static int _count; // 静态成员变量声明 Person(const string& name) : _name(name) { _count++; } ~Person() { _count--; } static void PrintCount() { // 静态成员函数 cout << "Person count: " << _count << endl; } }; // 静态成员变量必须在类外定义和初始化 int Person::_count = 0; class Student : public Person { public: int _stuNum; Student(const string& name, int num) : Person(name), _stuNum(num) {} }; int main() { cout << "Initial Person::_count = " << Person::_count << endl; // 0 Person p1("Alice"); Person p2("Bob"); cout << "After creating 2 Persons:" << endl; cout << "Person::_count = " << Person::_count << endl; // 2 cout << "p1._name address: " << &(p1._name) << endl; cout << "p2._name address: " << &(p2._name) << endl; // 两个地址不同 Student s1("Charlie", 1001); Student s2("David", 1002); cout << "\nAfter creating 2 Students:" << endl; cout << "Person::_count = " << Person::_count << endl; // 4 cout << "Student::_count = " << Student::_count << endl; // 4！共享同一个变量 // 通过对象访问静态成员（不推荐，易混淆） cout << "p1._count address: " << &(p1._count) << endl; cout << "s1._count address: " << &(s1._count) << endl; // 地址相同！ // 通过类名访问（推荐方式） cout << "&Person::_count = " << &Person::_count << endl; cout << "&Student::_count = " << &Student::_count << endl; // 地址相同！ Person::PrintCount(); // 输出 4 Student::PrintCount(); // 输出 4，调用的是同一个函数 return 0; } // 输出示例： // Initial Person::_count = 0 // After creating 2 Persons: // Person::_count = 2 // p1._name address: 0x7ffd4a3b8a30 // p2._name address: 0x7ffd4a3b8a50 // // After creating 2 Students: // Person::_count = 4 // Student::_count = 4 // p1._count address: 0x55b1d8c6d010 // s1._count address: 0x55b1d8c6d010 // &Person::_count = 0x55b1d8c6d010 // &Student::_count = 0x55b1d8c6d010 // Person count: 4 // Person count: 4

从输出可以清晰看到：

1. _name作为普通成员，每个对象（p1,p2,s1,s2）都有自己独立的内存地址。
2. _count作为静态成员，无论通过Person类还是Student类访问，无论通过哪个对象访问，它的地址都是唯一的。Student类并没有创建自己的_count，它只是“继承”了访问基类Person中那个唯一_count的权限。
3. 静态成员函数PrintCount()也是如此，Student::PrintCount()实际上调用的是Person::PrintCount()。

4.2 内存模型解析：静态区与类作用域

理解这个现象需要了解C++程序的内存布局。一个运行中的程序，其内存通常分为以下几个区域：

• 栈（Stack）：存储局部变量、函数参数等。p1._name,s1._stuNum这些非静态成员变量就位于各自对象所在的内存块中（对象可能在栈上也可能在堆上，但成员在对象内部）。
• 堆（Heap）：动态分配的内存。
• 全局/静态数据区（Static/Global Data Area）：存储全局变量、静态变量。类的静态成员变量就存储在这里。

当编译器看到int Person::_count = 0;这行定义时，它会在全局数据区为_count分配内存，并将其与Person类的类作用域关联起来。这个变量在程序启动时就被初始化，生命周期贯穿整个程序。

当Student类继承Person时，编译器会将Person的成员（包括静态成员）的“访问权限”和“名称查找规则”整合到Student的作用域中。但对于静态成员，它整合的是“一个指向全局数据区那个特定变量的引用”，而不是“创建一份新拷贝的指令”。因此，Student::_count只是一个符号，它最终被链接到Person::_count所在的内存地址上。这就是“仅传使用权”的含义：派生类获得的是对基类已有静态资源的访问许可，而非资源的副本。

4.3 使用要点与常见陷阱

1. 初始化必须在类外进行这是新手最常见的错误。静态成员变量在类内只是声明，必须在类外的全局作用域进行定义和初始化。否则会导致链接错误（undefined reference）。

// 正确做法 class MyClass { public: static int value; // 声明 static const int const_value = 100; // 整型静态常量可以在类内初始化 static const double const_double; // 非整型静态常量仍需在类外定义 }; int MyClass::value = 0; // 定义并初始化 const double MyClass::const_double = 3.14159; // 定义并初始化

2. 访问方式：优先使用类名虽然可以通过对象（obj.static_member）访问静态成员，但这是一种糟糕的风格，极易产生误导，让人误以为静态成员是属于对象的。正确的做法是始终使用类名加作用域解析运算符（ClassName::static_member）。

3. 静态成员函数不能访问非静态成员静态成员函数没有this指针，因此它无法区分是哪个对象在调用它，自然也就无法访问需要对象上下文（this）的非静态成员变量和函数。它只能访问其他的静态成员。

class Logger { private: static vector<string> logEntries; // 静态容器，存储所有日志 string instanceTag; // 非静态成员，每个对象不同 public: Logger(const string& tag) : instanceTag(tag) {} void log(const string& msg) { // 非静态函数可以访问静态和非静态成员 logEntries.push_back(instanceTag + ": " + msg); } static void printAllLogs() { // 静态函数只能访问静态成员 for (const auto& entry : logEntries) { cout << entry << endl; } // cout << instanceTag << endl; // 错误！无法访问非静态成员 } }; vector<string> Logger::logEntries; // 定义静态成员

4. 多线程环境下的竞态条件由于整个继承体系共享一份静态数据，在多线程程序中，如果多个线程同时通过不同的派生类对象修改静态成员，就会发生数据竞争（Data Race）。这是极其危险的行为，可能导致数据损坏或程序崩溃。

class Counter { public: static int count; void increment() { ++count; } // 非线程安全！ }; int Counter::count = 0; // 线程函数 void threadFunc() { Counter c; for (int i = 0; i < 100000; ++i) { c.increment(); } } int main() { std::thread t1(threadFunc); std::thread t2(threadFunc); t1.join(); t2.join(); // count的最终值很可能不是200000，因为++count不是原子操作。 cout << Counter::count << endl; return 0; }

解决方案：使用互斥锁（std::mutex）、原子操作（std::atomic）或线程局部存储（thread_local，注意这会让每个线程有自己独立的副本，不再是全局共享）来保护静态成员。

#include <mutex> class SafeCounter { public: static int count; static std::mutex mtx; void increment() { std::lock_guard<std::mutex> lock(mtx); ++count; } }; int SafeCounter::count = 0; std::mutex SafeCounter::mtx;

5. 设计考量：何时使用继承中的静态成员？共享的静态成员非常适合用于实现整个类家族的“全局”状态或工具函数，例如：

• 对象计数器：统计所有基类及派生类创建的对象总数。
• 共享资源管理器：如一个全局的日志管理器、配置读取器或数据库连接池，整个继承体系中的类都需要使用。
• 工厂方法：静态的工厂函数，用于创建继承体系中的不同派生类对象。
• 常量配置：定义一些整个家族通用的常量。

但是，如果你发现不同的派生类需要语义上独立、值不同的“静态”成员，那么就不应该将其放在基类中作为静态成员。正确的做法是在每个派生类中分别定义自己的静态成员，或者重新考虑设计，使用非静态成员并通过其他模式（如策略模式）来管理状态。

5. 综合对比与关联问题剖析

5.1 友元继承 vs 静态成员继承：机制对比表

为了更清晰地把握这两个特性的区别，我们可以从多个维度进行对比：

5.2 与菱形继承、多态性的关联思考

这两个问题虽然独立，但常与更复杂的继承问题一同出现。例如在菱形继承场景中：

class Base { protected: static int sharedResource; friend void manipulateBase(Base&); }; int Base::sharedResource = 0; class Derived1 : virtual public Base { /* ... */ }; class Derived2 : virtual public Base { /* ... */ }; class Final : public Derived1, public Derived2 { /* ... */ };

• 静态成员：无论继承结构多复杂（单继承、多继承、菱形虚拟继承），Base::sharedResource始终只有一份。Derived1、Derived2和Final都共享它。
• 友元：函数manipulateBase是Base的友元，它可以访问Base对象的私有部分。如果它接收一个Final对象的引用并向上转型为Base&，它仍然只能访问从Base继承下来的那部分成员中的私有/保护内容，而不能访问Derived1、Derived2或Final自身新增的私有成员。虚拟继承解决了数据冗余和二义性，但丝毫不改变友元关系的规则。

在与多态性结合时，情况也类似。通过基类指针或引用调用虚函数，可以实现运行时多态。但友元关系和静态成员访问是编译时确定的，与动态类型无关。一个基类指针指向派生类对象时，通过该指针访问静态成员，访问的仍然是基类定义的那一份。友元函数通过基类引用参数接收派生类对象，其友元权限也仅限于该基类。

5.3 实战中的设计替代方案

理解了这些限制后，我们在设计时可以有更优的选择：

替代友元的方案：

1. 提供公开或保护的访问接口：这是首选。如果派生类需要让外部访问其内部状态，考虑提供getter/setter函数。如果是为了让特定协作类高效访问，可以考虑将这两个类的关系改为组合，或者使用传递引用/指针的方式，在类内部完成操作后返回结果。
2. 使用内部类（Nested Class）：如果两个类关系极其紧密，可以将一个类定义为另一个类的内部类。内部类默认是外部类的友元（取决于C++标准版本，通常私有成员不可访问，但现代C++中嵌套类有特殊访问规则，需查阅标准），这有时能提供更清晰的封装。
3. 传递函数对象或Lambda：通过策略模式或回调函数，让外部代码将操作逻辑传入，由类内部自己执行对私有成员的访问。

管理“类家族”状态的方案（替代全局静态成员）：

1. 单例模式（Singleton）：如果需要管理整个继承体系共享的复杂资源（如配置、连接池），使用单例模式比静态成员变量更灵活、更易于控制初始化和销毁顺序。
2. 依赖注入（Dependency Injection）：将共享资源作为参数，通过构造函数或设置函数传递给需要它的基类和派生类对象。这降低了耦合度，便于测试。
3. 每个派生类独立的静态成员：如果不同派生类确实需要独立的状态，就在每个派生类中分别声明和定义自己的静态成员。虽然会重复一些代码，但语义更清晰。
4. CRTP（奇特的递归模板模式）：这是一种高级技巧，通过模板让每个派生类拥有自己独立的“静态”成员类型，但实现复杂，可读性较低，仅在性能关键的泛型编程中考虑。

6. 常见问题排查与调试技巧

在实际开发中，围绕这两个特性的问题往往表现为编译错误或运行时逻辑错误。下面是一些典型的排查思路。

6.1 编译错误：“无法访问私有成员”

错误场景：你在一个基类的友元函数中，尝试访问派生类对象的、派生类独有的私有成员。编译器提示：error: ‘int Student::_stuNum’ is private within this context排查步骤：

1. 确认调用关系：检查出错行所在的函数，是否是某个类的友元？
2. 确认访问目标：检查试图访问的成员变量或函数，属于哪个类（基类还是派生类）？
3. 检查友元声明：如果访问目标是派生类的私有成员，则该函数必须是该派生类的友元。去派生类的定义中查看是否有对应的friend声明。
4. 解决方案：在派生类中添加友元声明。如果该函数需要访问多个不同派生类的私有成员，可能需要重新审视设计，考虑是否可以通过公共虚函数来替代。

6.2 链接错误：“未定义的引用”

错误场景：你声明了一个静态成员变量，但在链接时报告找不到定义。编译器提示：undefined reference toClassName::staticVar‘`排查步骤：

1. 找到声明：在类定义内部找到static变量的声明。
2. 查找定义：在类外部（通常是.cpp源文件）查找该变量的定义。格式必须为：类型 ClassName::变量名 = 初始值;
3. 常见疏忽：
   • 忘记写了定义。
   • 定义写在了头文件里，导致多个编译单元包含，引发重复定义错误（multiple definition）。静态成员变量的定义应该放在.cpp文件中，除非是整型静态常量并在类内初始化了。
   • 拼写错误或作用域错误。

6.3 逻辑错误：静态数据意外共享

错误场景：你为基类设计了一个静态ID生成器，希望每个派生类对象都有唯一的ID，但发现不同派生类的对象ID混在了一起，或者所有对象的ID都是同一个。错误代码示例：

class GameObject { protected: static int nextId; // 意图：下一个可用的ID int id; public: GameObject() : id(nextId++) {} // 以为每个对象会获得递增的ID }; int GameObject::nextId = 0; class Player : public GameObject { /* ... */ }; class Enemy : public GameObject { /* ... */ }; Player p1, p2; Enemy e1, e2; // 你期望: p1.id=0, p2.id=1, e1.id=0, e2.id=1 (每个类独立计数) // 实际结果: p1.id=0, p2.id=1, e1.id=2, e2.id=3 (所有对象共享一个计数器)

问题根源：nextId是GameObject的静态成员，Player和Enemy都共享它。所以ID序列是全局递增的，而不是按类区分。解决方案：

• 方案A（每个类独立计数器）：在每个派生类中定义自己的静态计数器。

  class Player : public GameObject { private: static int nextPlayerId; // Player自己的计数器 public: Player() : GameObject() { id = nextPlayerId++; } // 需要重新思考id赋值逻辑 }; int Player::nextPlayerId = 0; // 类似地定义Enemy...

  但这样id的赋值逻辑变得复杂，且GameObject的构造函数可能不适用。
• 方案B（使用CRTP）：一种更优雅但较复杂的模板方案，让每个派生类拥有独立的静态成员类型。
• 方案C（重新设计）：放弃在基类中用静态成员实现ID生成。可以考虑使用一个全局的ID工厂类，或者让每个对象在构造时传入ID。

6.4 多线程下的数据竞争调试

现象：程序在多线程运行时偶尔崩溃，或静态成员的值出现非预期结果。调试方法：

1. 使用线程安全工具：使用std::atomic替代普通的静态类型。

   class Counter { public: static std::atomic<int> count; void safeIncrement() { ++count; } // 原子操作，线程安全 }; std::atomic<int> Counter::count{0};

2. 使用互斥锁：对于复杂的静态数据结构（如static std::vector），使用std::mutex进行保护。
3. 静态成员函数内的局部静态变量：有时，你可以将共享状态封装在静态成员函数内部的局部静态变量中。在C++11以后，局部静态变量的初始化是线程安全的。

   class Logger { public: static Logger& instance() { static Logger logger; // C++11保证线程安全初始化 return logger; } void log(const string& msg) { std::lock_guard<std::mutex> lock(mtx_); // 内部操作仍需加锁 // ... 记录日志 } private: std::mutex mtx_; Logger() = default; // 私有构造函数，实现单例 };

理解C++继承中友元和静态成员的特殊行为，是迈向高级C++程序员的必经之路。这不仅仅是记忆语法规则，更是理解语言设计者如何在“代码复用”、“封装安全”和“运行效率”之间取得平衡。下次当你的代码在继承和友元上编译报错时，或者发现静态数据行为诡异时，希望这篇文章能帮你快速定位到问题的根源。记住，在C++里，继承给你的是“是一个”的关系和成员的访问权，而不是基类所有的社会关系（友元）和全局家产（静态成员）的自动分配。