conan将跨平台开发与交叉编译统一为按settings生成目标二进制包；判断依据是os/arch是否与宿主机一致，不一致即为交叉编译；构建标志应优先通过tools.build:cxxflags配置，而非cmake内部变量。
Conan 本身不区分“跨平台开发”和“交叉编译”——它把这两件事统一成一个动作：按目标平台配置生成对应二进制包。 区别只在你如何描述需求，而 Conan 的实际行为取决于你传给它的 settings（比如 os、arch、compiler）是否与当前构建机一致。
conan install 时 os/arch 不匹配当前机器就是交叉编译
当你在 x86_64 Linux 主机上执行：
conan install . --build=missing -s os=Android -s arch=arm64 -s compiler=clang -s compiler.version=15
Conan 就会去拉取或构建 Android arm64 的二进制包。这本质就是交叉编译——宿主机不能运行产出的库或可执行文件。
- 关键判断依据是
os和arch是否与宿主机原生一致（可用conan profile show default查看当前 profile） - 即使
os=Linux，只要arch=armv7而宿主机是x86_64，也算交叉 - Conan 不关心你用的是 NDK、Sysroot 还是裸工具链，它只管按
settings拉/构二进制，具体怎么编译交给conanfile.py里的build()或 CMake 工具链
conanfile.py 中的 tools.build:cxxflags 不等于 CMake 的 CMAKE_CXX_FLAGS
Conan 的 tools.build:cxxflags 是全局构建上下文标志，会被注入到所有构建系统中；而 CMake 的 CMAKE_CXX_FLAGS 只影响 CMake 自身逻辑，且容易被子项目覆盖。
- 在
conanfile.py的configure()或generate()阶段设置self.conf.define("tools.build:cxxflags", ["-mfloat-abi=hard"])，比在 CMakeLists.txt 里硬写set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mfloat-abi=hard")更可靠 - 如果同时用了
CMakeToolchain，Conan 会自动把tools.build:cxxflags映射进conan_toolchain.cmake，但不会反向同步 - 常见坑：在 CMakeLists.txt 里用
add_compile_options()加标志，结果被 Conan 的 toolchain 覆盖或忽略——优先走 Conan 的 conf 管理
CONAN_CMAKE_TOOLCHAIN_FILE 和 CMAKE_TOOLCHAIN_FILE 的加载顺序很关键
Conan 2.x 默认会生成自己的 toolchain 文件（如 conan_toolchain.cmake），如果你又手动设置了 CONAN_CMAKE_TOOLCHAIN_FILE 指向自定义文件，两者会叠加，但顺序决定谁生效。
- Conan 先加载
CONAN_CMAKE_TOOLCHAIN_FILE（即你指定的外部文件），再追加自身生成的逻辑 - 如果你的外部 toolchain 里写了
set(CMAKE_SYSTEM_NAME "Linux")，但 Conan 的settings.os=Android，最终 CMake 仍会以 Android 为准——因为 Conan 后续会重设CMAKE_SYSTEM_NAME - 真正容易出错的是：自定义 toolchain 里误写了
set(CMAKE_C_COMPILER ...)，而 Conan 已通过tools.cmake.cmaketoolchain:generator指定了 Ninja，导致 generator 冲突报错CMAKE_C_COMPILER is not set
最常被忽略的一点：Conan 的交叉能力不是靠“切换命令”实现的，而是靠 settings + conf + profile 三层声明式约束。一旦 profile 里 os 和宿主机不一致，后续所有依赖解析、构建、打包行为就自动进入交叉模式——你不需要改代码，也不需要换命令，只需要确保 profile 对得上目标平台。
