在 Ubuntu 里，C++ 库文件并不是随意摆放的：通过 APT 安装的系统库、自己源码编译安装的第三方库、以及 GCC 运行时依赖，通常各有固定目录。把这些路径分清楚之后，遇到“头文件找不到”或“链接不到库”时，就能更快判断问题出在安装位置、编译参数，还是编译器默认搜索范围。
下面按最常见的几类目录来梳理，并配合命令说明如何确认库文件到底放在哪、编译器默认会去哪里找。
系统通过包管理器安装的库放在哪里
如果库是通过 APT 这类包管理器安装的，最常见的落点是 /usr 体系下的标准目录。这一类路径通常也是系统工具链最先识别的地方。
/usr/lib：系统库的常规目录
/usr/lib 是系统级库文件的默认目录之一。这里会放很多由发行版软件包提供的库文件，包括动态链接库 .so 和静态库 .a。像 C++ 标准库相关文件、C 运行库相关文件，通常都能在这一层级里找到对应内容。
例如文中提到的 libstdc++.so、libc.so，都属于这一类系统提供的基础库。实际排查时，如果你安装的是发行版官方包，优先检查这里通常不会错。
/usr/lib/x86_64-linux-gnu/：64 位架构相关库目录
在 64 位 Ubuntu 中，更核心也更常见的实际目录往往是 /usr/lib/x86_64-linux-gnu/。这是架构特定的库目录，专门存放面向当前平台的二进制库文件。
比如 libstdc++.so.6、GCC 运行时相关库等，通常就在这里。可以把它理解为 /usr/lib 下更细分的一层：前者偏通用入口，后者则明确绑定当前机器架构。
如果你的程序在链接阶段提示某个 .so 找不到，而该库又是系统包安装的，那么这个目录往往比单纯查看 /usr/lib 更有价值。
/usr/include/c++/：C++ 标准库头文件目录
除了库文件本体，系统安装的 C++ 头文件也有固定位置。标准库头文件通常放在 /usr/include/c++/ 下，并按 GCC 版本分目录保存。
例如：
/usr/include/c++/11/这表示对应 GCC 11 的标准库头文件路径。像 iostream、vector 这样的常用头文件，都在这一类目录中。
一般情况下，编译器会默认搜索这些标准路径，所以使用标准库头文件时不需要手动追加 -I 参数。这也是为什么绝大多数 C++ 程序直接写 #include <iostream> 就能通过编译。
手动编译安装的第三方库通常放在哪里
如果不是通过包管理器安装，而是自己下载源码后执行安装流程，那么文件大多会进入 /usr/local 体系。这样做的目的，是把“系统自带内容”和“本地手动安装内容”分开，减少相互覆盖或冲突的风险。
/usr/local/lib：手动安装库的默认位置
/usr/local/lib 是手动安装库文件最常见的目录。像通过源码编译安装的 OpenCV、Boost，或者某些第三方软件包，安装完成后往往会把动态库和静态库放到这里。
这一点在排查问题时很重要：如果你明明已经编译安装过某个库，但系统路径下找不到，优先去 /usr/local/lib 看，通常更符合实际情况。
把手动安装内容单独放在 /usr/local，还有一个直接好处，就是不会轻易覆盖由系统包管理器维护的文件，后续升级和清理也更容易区分来源。
/usr/local/include：第三方头文件目录
与库文件对应，手动安装的头文件通常位于 /usr/local/include。很多库会再建一层自己的子目录，例如：
/usr/local/include/library_name/这样做可以避免不同项目的头文件重名。
这里要特别注意一点：这类路径不一定总在你的编译参数里被正确使用。原文给出的建议是，编译时记得通过 -I 指定头文件路径，否则编译器可能找不到对应头文件。
也就是说，当你已经确认头文件存在，但编译器仍然报找不到 #include 时，优先检查的不是文件本身，而是编译命令里是否包含了正确的 -I 选项。
GCC 相关运行时库在哪一层
除了系统库和第三方库，还有一类经常被忽略的目录：编译器自身的运行时支持库。这些内容虽然平时不一定需要手动链接，但它们确实参与了编译和链接过程。
/usr/lib/gcc/x86_64-linux-gnu/<版本号>/
GCC 的运行时库和支持库通常放在：
/usr/lib/gcc/x86_64-linux-gnu/<版本号>/例如：
/usr/lib/gcc/x86_64-linux-gnu/11/这个目录里常见的是编译器需要的辅助库，例如 libgcc_s.so。它们不一定是你在命令行中显式写出并直接链接的目标，但编译器在后台处理构建流程时经常会用到。
因此，遇到和 GCC 版本、运行时兼容性有关的问题时，不能只盯着 /usr/lib 或 /usr/local/lib，还要把这一层路径考虑进去。
不知道库在哪时，怎么快速查找
如果你已经知道库名，或者至少知道前缀，那么直接查路径通常比凭经验猜目录更高效。Ubuntu 下有几条很实用的办法，可以分别解决“查得快”“查得准”“看默认搜索路径”这三类问题。
用 locate 快速全局定位
locate 适合做快速匹配搜索。先更新数据库：
sudo updatedb然后执行：
locate libname它会列出系统中所有匹配 libname 的路径。优点是速度快，尤其适合你已经大致知道库名、只是不确定具体目录的时候。
它的前提也很明确：要先有最新索引，所以第一次使用或者系统变动较大后，记得先跑一次 updatedb。
用 find 精确搜索目录树
如果你想直接在指定目录下递归查找，可以使用：
find /usr -name "libname*"例如查找 Boost 相关库：
find /usr -name "libboost_*"find 的好处是结果直接来自当前文件系统，不依赖预先建立的数据库，所以更适合做精确确认。代价是搜索速度通常比 locate 慢一些。
用 g++ 查看默认头文件搜索路径
当问题不在“库文件在哪”，而在“编译器默认会不会去这个目录找头文件”时，可以执行：
g++ -v -x c++ -E /dev/null输出内容中，#include <...> 段落列出的路径，就是 g++ 默认搜索头文件的位置。
这个方法的价值在于，它能把“编译器实际行为”直接展示出来。遇到头文件路径判断不准的情况，不必反复猜测，直接看编译器自己的搜索列表通常最可靠。
实际排查时可以怎么判断
把上面的路径合在一起看，判断思路其实很直接。
如果库是通过包管理器安装的，先看 /usr/lib 和 /usr/lib/x86_64-linux-gnu/；如果是标准库头文件，再看 /usr/include/c++/ 下对应 GCC 版本目录。若库是自己源码安装的，则重点检查 /usr/local/lib 和 /usr/local/include。
如果仍然不确定文件到底在不在，就用 locate libname 或 find /usr -name "libname*" 直接查；如果文件明明存在，却还是编译报错，那就进一步用 g++ -v -x c++ -E /dev/null 检查编译器默认搜索路径。
对 Ubuntu 下的 C++ 开发来说，弄清楚这些目录的分工，比单纯记住某一个绝对路径更有用。因为真正遇到问题时，决定排查效率的往往不是“会不会找”，而是能不能先判断应该去哪个层级找。
