将C++项目依赖直接放入项目会有哪些问题？为何用find_package()？

你提到的直接嵌入依赖的方式，在小项目、短期开发或者离线场景下确实省心，但长期来看会埋下不少隐患，而find_package()解决的正是这些痛点：

直接嵌入依赖的隐藏问题 #

• 仓库臃肿不堪：把依赖的完整源码都塞进自己项目，尤其是像Qt、Boost这类大依赖，仓库体积会瞬间膨胀几倍，克隆、拉取慢不说，还占满存储空间。要是依赖本身还有嵌套子依赖，情况只会更糟。
• 维护成本爆炸：依赖出了安全补丁、功能更新，你得手动去它的仓库拉代码替换，还要处理编译适配问题——比如新版本改了API，你得跟着调整自己的代码。用find_package的话，vcpkg、apt这类包管理器一键就能更新所有依赖，省超多事。
• 编译速度拖后腿：每次编译你的项目，所有嵌入的依赖都得跟着重新编译（除非你手动折腾缓存），哪怕依赖半个月没动过。而find_package可以直接用预编译好的二进制包，编译速度能快好几倍。
• 版本冲突坑队友：如果你的项目被别人当作依赖引入，对方也嵌入了同个依赖但版本不同，就会出现重复定义、API不兼容的崩溃问题。find_package遵循CMake的依赖查找规范，能统一管理版本，避免这种踩坑。
• 跨平台适配头疼：Windows下看似顺畅，但到了Linux、macOS，嵌入的依赖可能没适配当地的编译工具链、系统库，你得手动改依赖的CMake配置才能编译过；find_package会自动适配目标平台的标准路径和规则，不用你瞎折腾。

find_package()的核心优势 #

• 依赖复用不重复造轮子：可以直接用系统已装的依赖，或者包管理器统一管理的版本，不用重复存储、编译同一份代码。
• 标准化配置易维护：遵循CMake官方的依赖查找规范，所有项目的依赖引入方式统一，其他开发者接手时一眼就能看懂，不会因为你的自定义libs结构懵圈。
• 版本控制更灵活：用find_package(XXX REQUIRED VERSION 2.3.4)就能精确指定版本，还支持版本范围，配合包管理器能自动满足版本要求，不用手动找对应版本的源码。
• 省出时间写业务代码：依赖的编译、安装、更新都交给系统或包管理器处理，你不用再花时间折腾依赖的编译配置，专注写自己的项目就行。

折中方案：兼顾便捷与可维护性 #

如果确实需要项目克隆后直接就能编译（比如离线环境），可以用Git子模块配合add_subdirectory，但要注意：

• 只在必要时用：比如依赖没有官方包，或者需要某个特殊修改的版本。
• 定期更新子模块：同步依赖的安全补丁和功能更新，别让依赖停留在老旧版本。
• 加个条件判断：在CMake里先尝试用find_package找系统依赖，找不到再用子模块的版本，兼顾灵活性和兼容性。

内容的提问来源于stack exchange，提问作者purepelmen