关键在于构建系统统一编译链接所有.cpp文件：g++一次传入多个源文件，或用CMake在add_executable中显式列出；头文件需正确声明、定义分离并防重复包含；依赖关系决定增量编译。
怎么让编译器知道多个 .cpp 文件都属于同一个项目
关键不是“添加”，而是让构建系统把所有 .cpp 文件一起编译、再链接成一个可执行文件。C++ 本身没有“项目”概念，这是构建工具（如 g++、clang++、CMake、MSVC）负责的事。
最直接的方式是把所有源文件一次性传给编译器：
g++ main.cpp utils.cpp network.cpp -o myapp
这样 g++ 会分别编译每个 .cpp，再自动链接。注意：顺序一般不重要，但若存在强符号冲突（比如两个 .cpp 都定义了同名的非 inline 全局函数），会报 multiple definition 错误。
- 所有
.cpp必须能独立通过预处理和语法检查（即各自包含所需的头文件） - 不要在多个
.cpp里重复定义非static或非inline的同名函数/变量 - 头文件要加
#pragma once或卫哨宏，避免被多次包含导致重定义
用 CMakeLists.txt 管理多个源文件时常见写法
CMake 是目前主流选择，它把源文件列表显式声明出来，比命令行更易维护。
立即学习“C++免费学习笔记（深入）”；
最小可用示例：
cmake_minimum_required(VERSION 3.10) project(MyApp) <p>add_executable(myapp main.cpp utils.cpp network.cpp )
运行 cmake . && make 后，CMake 就会生成对应构建规则，确保三个文件都被编译并链接。
-
add_executable()的第二个及后续参数就是源文件路径，支持相对路径（如src/main.cpp） - 如果文件分散在子目录，用
file(GLOB ...)可批量收集，但不推荐用于生产——它不会自动触发重新配置，改了文件名可能漏编译 - 头文件不用列在这里，只要
#include路径正确（靠target_include_directories()设置）
为什么改了某个 .cpp，只重新编译它而不是全部
因为现代构建系统默认启用“增量编译”：每个 .cpp 编译成独立的 .o（目标文件），只有源文件或它依赖的头文件修改了，才重新编译对应 .o；最后一步链接始终要执行，但很快。
这依赖于正确的依赖关系描述。CMake 自动生成依赖信息，而手写 Makefile 时容易漏掉 .h 文件依赖，导致改了头文件却不重编相关 .cpp。
- 用
g++ -M可手动查看某.cpp实际依赖哪些头文件 - VS 和 Clion 默认开启依赖追踪；GCC/Clang 配合 CMake 也默认可靠
- 若发现改了
utils.h却没重编main.cpp，大概率是main.cpp没#include "utils.h"，或用了错误的包含路径
多个源文件之间怎么共享函数和类
靠头文件声明 + 源文件定义的经典分离方式。例如想在 main.cpp 中调用 do_work()，而它实现在 utils.cpp 里：
utils.h：
void do_work(); // 声明，放头文件
utils.cpp：
#include "utils.h"
void do_work() { /* 实现 */ } // 定义，放源文件main.cpp：
#include "utils.h"
int main() { do_work(); }链接阶段会把 main.o 中对 do_work 的引用，和 utils.o 中的定义拼起来。
- 不要在
utils.cpp里写extern void do_work();——那是给外部定义用的，自己定义时不需要 - 类的声明通常全放在头文件，成员函数实现可内联（头文件里）或外置（
.cpp里），后者更适合复杂逻辑 - 全局变量若需跨文件访问，头文件中用
extern int g_value;，仅在一个.cpp里写int g_value = 42;
实际协作中，最容易被忽略的是头文件包含路径和符号可见性边界——不是文件放在一起就自动互通，得靠 #include 和链接器规则真正连通。
