类前置声明仅在指针/引用声明、函数声明、友元声明中安全；涉及内存布局、成员访问、构造析构或模板实例化时必须有完整定义。
类前置声明只在指针/引用场景下安全可用
编译器看到 class X; 时，只知道 “X 是个类”，不知道它多大、有哪些成员、能否构造或析构。所以只要不涉及内存布局或成员访问，就能过编译。
以下写法合法：
-
X* ptr;或X& ref;—— 指针和引用大小固定，无需 X 的完整定义 -
void f(const X& x);或X* create();—— 函数声明只用类型名，不触发实例化 -
friend class X;—— 友元声明不依赖 X 的内部结构
但一旦出现 X obj;、sizeof(X)、obj.member、static_cast<x>(y)</x> 或继承 class Y : public X，就会报 error: invalid use of incomplete type 'class X'。
头文件里用前置声明，.cpp 里才 #include 完整定义
这是最常见也最稳妥的模式：头文件（.h）只声明接口，用 class X; 配合 X* 或 std::unique_ptr<x></x>；实现文件（.cpp）里再 #include "X.h"。
这样做的关键好处是解耦：
- 修改
X.h时，只有直接包含它的 .cpp 文件需要重编译，不会连带所有用到X*的头文件一起 rebuild - 避免 A.h 包含 B.h、B.h 又包含 A.h 的循环依赖
-
std::unique_ptr<x></x>在头文件中可仅靠前置声明，但不能调用reset()、get()或解引用（*ptr），否则会要求 X 的析构函数可见
别对 std::shared_ptr 抱太大期望
std::shared_ptr<x></x> 确实比 unique_ptr 更“懒”：构造、赋值、拷贝本身不要求 X 完整定义，所以头文件里写 std::shared_ptr<x> p;</x> + class X; 是 OK 的。
但只要出现以下任一操作，就必须在 .cpp 里 #include "X.h"：
-
p->func()—— 需要知道 X 的成员函数签名 -
*p—— 解引用需要 X 的完整布局 -
p.reset(new X)—— new 表达式需要 X 的构造函数
更隐蔽的坑：std::make_shared<x>()</x> 必须看到 X 的完整定义，不能在头文件里直接用。
模板、std::string、std::vector 这些一律不能前置声明
标准库类型不是“普通类”，它们的行为严重依赖模板参数和内部实现细节。例如：
-
std::string不是单一类型，而是std::basic_string<char></char>的别名，前置声明class std::string;是未定义行为（UB） -
std::vector<x></x>实例化时需要知道 X 的完整定义（比如拷贝构造、析构），光有class X;不够 - 哪怕你只写
std::vector<x>::size_type</x>，编译器也得展开整个模板，必须看到X和std::vector的完整声明
结论很直白：所有标准库容器、字符串、智能指针（除了上面讨论的 unique_ptr/shared_ptr 成员声明场景）、流类型，都必须 #include 对应头文件，别试前置声明。
最容易被忽略的是：哪怕你只在头文件里写了 std::vector<x> m_data;</x>，就必须同时确保 X 完整定义可见——这时前置声明 class X; 就不够用了，得把 X.h 也 include 进来。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
