Conan不直接传递-lxxx/-L参数，而是通过CMakeDeps和CMakeToolchain生成器将依赖信息转为CMake可识别的target（如openssl::ssl），需确保recipe中正确设置cpp_info.libs和cmake_target_name，且CMakeLists.txt中调用find_package(CONFIG)并使用target_link_libraries链接对应target。
conan install 时无法让下游拿到 -lxxx 或 -L/path 参数？
Conan 本身不直接传递裸链接参数（如 -lssl、-L/opt/lib）给 CMake 或 Makefile。它传递的是「已解析的依赖图」和「封装好的构建信息」，最终由生成器（generator）转成目标构建系统能理解的形式。你看到链接失败，大概率是 generator 选错、conanfile.py 中没暴露库或没设 cpp_info.libs，或者 CMake 没正确 consume 这些信息。
CMakeLists.txt 里 find_package(XXX) 失败，但 conan install 成功了？
这是典型的信息断层：Conan 安装成功 ≠ CMake 能自动发现库。你需要显式把 Conan 提供的路径注入 CMake 上下文。关键点有三个：
-
conan install . --generator CMakeDeps（生成xxx-deps.cmake）和--generator CMakeToolchain（生成conan_toolchain.cmake）必须同时用，缺一不可 - CMakeLists.txt 开头必须包含：
include(${CMAKE_BINARY_DIR}/conan_toolchain.cmake)，再调用find_package(xxx CONFIG) - 如果依赖包（比如
openssl/3.0.10）在它的conanfile.py中没设置self.cpp_info.libs = ["ssl", "crypto"]，那find_package()就找不到导出的 target，自然也不会带链接参数
想手动加 -Wl,--no-as-needed 或 -static-libstdc++ 怎么办？
这类参数不属于依赖本身的链接需求，而是构建策略。不能塞进 requires，也不该靠改远程包 recipe。正确做法是在 consumer 项目（你的主 conanfile.py）中通过 self.cpp_info.system_libs 或 self.cpp_info.exelinkflags 注入：
-
self.cpp_info.exelinkflags.extend(["-Wl,--no-as-needed"])→ 影响可执行文件链接 -
self.cpp_info.sharedlinkflags.extend(["-static-libstdc++"])→ 影响动态库链接 - 注意：这些 flag 只对当前包生效；若要透传给它的下游，需在
package_info()里显式 propagate，例如：self.cpp_info.exelinkflags = self.dependencies["openssl"].cpp_info.exelinkflags + ["-Wl,--no-as-needed"]
为什么 CMake 生成的 link.txt 里还是没看到 -lxxx？
最常被忽略的一点：CMake 的 target_link_libraries(myapp PRIVATE openssl::ssl) 写法，依赖的是 CMakeDeps 生成的 openssl-config.cmake 是否导出了 openssl::ssl 这个 target。而这个 target 是否存在，取决于上游包的 cpp_info.set_property("cmake_target_name", "openssl::ssl") 和 cpp_info.libs 是否非空。很多老 recipe（尤其 Conan 1.x 时代）只设了 libs 却没设 cmake_target_name，结果 CMake 找到 config 文件，但里面没定义任何 target —— 看似成功，实则静默失效。
