fruit 编译失败主因是未链接库且漏配 find_package 和 target_link_libraries；autumn 无包管理、宏特化易错；二者均不支持智能指针自动管理，生命周期需手动把控。
Google Fruit 编译失败：找不到 fruit 命名空间
根本原因是 Fruit 不是头文件库，必须链接编译好的静态/动态库，且 CMake 配置容易漏掉 find_package(fruit REQUIRED) 或 target_link_libraries(... fruit::fruit)。它不支持纯 header-only 用法，和 C++20 的 std::ranges 那种即用即包含完全不同。
常见错误现象：error: 'fruit' has not been declared，或链接时报 undefined reference to 'fruit::Injector<...>::create<...>()'</...></...>。
- 确认你用的是 Fruit 官方 GitHub release（不是某个 fork 的未发布分支），v3.8.0 起才正式支持 C++17，旧版本在 GCC 11+ 下会编译失败
- CMakeLists.txt 中必须显式添加
find_package(fruit REQUIRED)，然后用target_link_libraries(your_target PRIVATE fruit::fruit)，不能只include_directories(...) - Fruit 的
Injector类型擦除开销比手写工厂略高，高频创建场景（如每帧 new 一个 service）建议缓存Injector实例，别每次临时构造
Autumn 没有文档也找不到包管理器集成
Autumn 是一个极简、无依赖的单头文件 DI 库，但官方没提供预编译包，也没进 vcpkg/conan 官方源。它的“轻量”代价是几乎零封装 —— 所有绑定都靠宏 + 模板特化，出错时编译器报错信息非常晦涩。
使用场景：适合嵌入式或对二进制体积敏感的小型项目，不适合需要运行时模块热插拔或复杂生命周期管理的系统。
- 直接下载
autumn.h放进项目 include 目录即可，无需构建；但必须定义AUTUMN_IMPLEMENTATION一次（通常在某个 .cpp 文件顶部） - 绑定接口时必须手动特化
autumn::Binder，比如template struct autumn::Binder<myservice> { static MyService* create() { return new MyServiceImpl; } };</myservice>—— 少一个static或返回类型不匹配，就是一长串 SFINAE 错误 - 不支持构造函数参数注入（比如依赖另一个 service），所有依赖必须提前注册并全局可访问；想传参得自己写 factory wrapper
fruit::Injector 构造后立即崩溃：循环依赖没被检测出来
Fruit 默认在 Injector 构造时做依赖图拓扑排序，但只检查直接构造函数参数层级的循环，对间接依赖（比如 A 依赖 B，B 依赖 C，C 又通过全局变量/单例间接拉回 A）完全无感。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
典型错误现象：程序启动时 SIGSEGV，堆栈停在 fruit::impl::BindingNormalizer::normalizeBindings() 内部，GDB 看不到清晰调用链。
- 开启 Fruit 的调试模式：编译时加
-DFRUIT_DEBUG=ON，它会输出绑定图 dot 文件，用 Graphviz 可视化检查环路 - 避免在绑定 lambda 里捕获外部对象（尤其是 this），lambda 捕获会绕过 Fruit 的依赖分析，变成隐式依赖
- 如果必须处理循环依赖，改用
fruit::Provider<t></t>延迟获取，而不是在构造函数里直接要T*；Provider 本身不触发实例化，安全
两个库都不支持 std::shared_ptr 自动管理生命周期
Fruit 和 Autumn 都默认返回裸指针（T*）或值拷贝，不会帮你 hold 住 std::shared_ptr 的引用计数。这不是 bug，是设计取舍 —— 它们假设你清楚对象所有权归属。
后果：如果你绑定了一个返回 std::shared_ptr<service></service> 的工厂函数，但 Fruit 注入点声明为 Service*，那拿到的就是 ptr.get()，shared_ptr 一出作用域，对象就被析构，后续访问必 crash。
- Fruit 中若需 shared_ptr，必须显式绑定为
std::shared_ptr<t></t>类型，且注入点也得声明为std::shared_ptr<t></t>；不能混用 - Autumn 完全不管智能指针，所有绑定都按你写的
create()函数返回类型走，返回std::shared_ptr就得自己确保析构逻辑正确 - 跨模块共享 service 时，裸指针 + 全局生命周期管理极易出错，这时候不如放弃 DI 框架，直接用静态局部变量 +
std::shared_ptr手动控制
Fruit 的编译依赖和 Autumn 的宏展开错误，是最常卡住人的两个点；而生命周期语义模糊，是后期维护时最易被忽略的隐患。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
