test_package 验证 conan 包在消费者项目中的集成可用性，即 find_package、#include、链接与运行是否成功，不验证库功能正确性；需包含 conanfile.py 和调用 api 的测试代码，支持跨平台但须注意 abi、rpath、符号导出等陷阱。
test_package 验证的是 consumer 使用场景是否真实可行
它不验证库本身的功能正确性（那是单元测试的事），而是验证：当别人把你的 Conan 包当作依赖引入自己的项目时，能否顺利 find_package、#include、链接、运行。本质是「集成可用性」的端到端检查。
常见错误现象包括：
-
Cannot open include file: 'xxx.h'（头文件路径没导出或 package() 里没拷贝） -
undefined reference to 'xxx::func()'（符号未导出、static 库未链接、C++ ABI 不匹配） - 动态库
dlopen失败或LoadLibrary报错（runtime 路径不对、依赖缺失、平台/架构不一致） - 测试程序编译通过但运行崩溃（如 Qt 插件路径未设置、Boost.Asio 未 link
pthread）
test_package 目录结构必须含 conanfile.py 和可执行测试代码
Conan 不会自动识别任意 C++ 源文件；它只认 test_package/conanfile.py 作为入口，并默认构建 test_package/test_package.cpp（或 .cc）为测试主程序。
关键点：
-
conanfile.py中的requires必须声明被测包，例如requires = "mylib/1.0" -
test_package.cpp必须实际调用被测包的 API，不能只#include就完事（否则链接阶段不会触发） - 若使用 CMake，
test_package/CMakeLists.txt必须调用find_package(mylib)并target_link_libraries，否则无法暴露链接问题 - 不支持纯头文件库（header-only）直接走默认流程——需在
conanfile.py中显式设no_copy_source = True并确保package_id()清理掉无关字段
conan create 执行 test_package 的时机和跳过方式
conan create 默认会在打包完成后立即进入 test_package 目录并执行完整流程（source → build → run）。这一步失败，整个 create 就算失败。
跳过方法只有两个有效选项：
- 加
-tf ""参数（Conan 2.1+）：conan create . -tf ""，彻底跳过 test_package - 临时重命名或移走
test_package目录（不推荐，破坏可复现性）
注意：--build=missing 不影响 test_package 是否执行；--test-folder 已被弃用，不要用。
容易被忽略的跨平台陷阱
test_package 在本地开发机上跑通 ≠ 在目标环境可用。尤其要注意：
- Windows 上 DLL 导出符号需
__declspec(dllexport)，且test_package必须用相同 ABI（MSVC 版本、运行时 /MT vs /MD）构建 - Linux/macOS 的 RPATH 设置是否包含
$ORIGIN或@rpath，否则运行时报libxxx.so not found - HarmonyOS PC 等新兴平台，
test_package运行时可能因缺少 OpenGL、QtWebEngine 等隐式依赖而崩溃——这时要像 BALL 项目那样，在test_package/conanfile.py中显式禁用 GUI 相关选项 - 交叉编译时，
test_package默认尝试在 host 上运行二进制，必须用--profile:build和--profile:host明确区分，否则报Exec format error
真正难的不是让 test_package 编译过去，而是让它在所有目标 profile 下都静默成功运行——这要求你把 consumer 的真实约束提前写进测试逻辑里。
