conan实现新成员5分钟跑通构建的关键在于环境可复现：必须显式声明settings（os/compiler/build_type/arch）、用conan.lock锁定依赖图、按环境拆分profile文件并提交至git，禁用--build=missing，确保conan install命令携带完整上下文。
新成员拉代码后5分钟内跑通构建，不是靠文档写得多，而是Conan能自动复现环境。关键不在“教人装什么”，而在让conan install这条命令本身携带全部上下文——编译器、标准库、架构、甚至CI用的Docker镜像标识。
conanfile.py里必须固化settings和options
很多人只写requires，却把settings留空或依赖默认值。这会导致新成员在不同机器上执行conan install时，因系统默认compiler.libcxx（如libstdc++ vs libstdc++11）或build_type不一致，触发重编译甚至链接失败。
-
settings = "os", "compiler", "build_type", "arch"必须显式声明，不能省略 - 对GCC/Clang项目，强制指定
compiler.libcxx=libstdc++11，避免Ubuntu 20.04+默认用libstdc++导致ABI不兼容 - Windows项目明确写
compiler.runtime=dynamic，否则MSVC新人可能用错运行时 - 所有
default_options要覆盖常见分歧点：比如"zlib:shared=True"、"openssl:no_shared=False"
用conan lock文件锁死整个依赖图
仅靠conanfile.py无法保证可复现——因为fmt/10.x这种版本范围在不同时间解析出的实际版本可能不同。新成员第一天拉代码，第二天拉，可能拿到两个不同的fmt/10.2.1和fmt/10.2.2二进制，而后者可能引入了破坏性变更。
- 首次配置好环境后立即运行：
conan lock create . -s compiler=gcc -s compiler.version=11 -s compiler.libcxx=libstdc++11 - 生成的
conan.lock必须提交到Git，且CI和新人均使用conan install . --lockfile=conan.lock - 不要用
--build=missing在开发机上随意重建；新人应优先拉取预编译二进制，用--build=never快速验证
profile文件要按环境拆分，别塞进全局配置
把compiler.version=11硬编码在conanfile.py里看似省事，实则埋雷：CI用GCC 12跑测试，本地却强制GCC 11，新人照着文档装完GCC 12发现构建失败，第一反应是“文档错了”。
- 在
profiles/目录下建gcc-11-release、gcc-12-debug、msvc-17-x64等文件，内容只含[settings]和[options] - 新人只需执行
conan install .. -pr=profiles/gcc-11-release，无需查自己GCC版本是否匹配 - CI脚本里直接指定
-pr=ci/gcc-12-docker，profile里甚至可以写[env]设置CC=/opt/gcc-12/bin/gcc，彻底屏蔽宿主机干扰
真正卡住新人的往往不是“不会装Conan”，而是conan install报错后不知道该看哪一行日志——是远程仓库连不上？还是本地profile里arch=x86但机器是x64？或是conan.lock里记录的openssl/3.0.10二进制根本没上传到公司私仓？这些细节不暴露在命令行参数里，就只能靠经验猜。
