build()仅编译不安装，应使用autotoolstoolchain和autotools驱动configure/make，禁用make install；路径须用self.source_folder/self.build_folder；平台逻辑交由settings/options驱动；build目录不跨构建持久化。
build() 方法只负责编译，不负责安装或打包
它对应的是传统 Autotools/CMake 项目中「运行 configure/make」这一步，仅产出二进制和头文件到本地构建目录（如 build/），不会把文件拷贝到 package/ 或写入 Conan 缓存。很多新手误以为 build() 应该调用 make install 或手动复制文件，这是错的——那属于 package() 的职责。
Autotools 项目中 build() 必须用 Autotools 辅助类驱动
直接写 self.run("configure && make") 是不可靠的：环境变量没注入、--prefix 不生效、交叉编译参数丢失。正确做法是配合 AutotoolsToolchain 和 Autotools：
-
AutotoolsToolchain在generate()阶段生成conan_toolchain.mak等文件，并设置--prefix=/（逻辑路径，非真实系统根目录） -
build()中用autotools.configure()自动读取上述参数，再调用autotools.make() - 不要在
build()里写make install；那是package()用copy()干的事
build() 里不能依赖 source_folder 外的路径
Conan 会把源码复制到临时 source/ 目录再执行 build()，所以任何硬编码的绝对路径（比如 /home/user/mylib/src）都会失效。常见错误包括：
- 在
build()里调用self.run("gcc -I../include ...")——..指向的是构建根目录，不是源码根目录 - 用
os.path.join(os.getcwd(), "src")获取源码路径 —— 当前工作目录是build/，不是source/ - 正确做法：始终用
self.source_folder或self.build_folder拼路径，或在generate()阶段把必要路径传给构建系统
build() 不该做平台判断或条件编译逻辑
平台适配、编译器开关、shared/static 切换等，应由 settings 和 options 驱动，在 configure() 或 CMakeLists.txt 里处理。在 build() 里写 if self.settings.os == "Windows": self.run("nmake") 属于反模式：
- 破坏 Conan 的配置一致性模型，
package_id可能无法准确反映实际产物差异 - 让同一 recipe 在不同 profile 下行为不一致，难以复现构建结果
- 正确方式：用统一构建系统（如 CMake）+
CMakeToolchain，让构建脚本自己适配
self.build_folder）生命周期仅限本次构建，Conan 不保证它跨 conan create 调用存在；如果你在 IDE 里反复调试，又想复用中间产物，得靠 conan export-pkg + 手动管理构建缓存，而不是指望 build() 自动保留。
