profile 中的 settings 直接参与 package_id 计算，决定二进制唯一性；options 默认不参与，除非 recipe 显式纳入；profile 未写全 settings 会导致 id 不稳定，且无法绕过 recipe 的 validate 或 package_id 逻辑。
Profile 里的 settings 直接参与 package_id 计算
Conan 的 package_id 不是凭空生成的，它严格依赖当前构建上下文中的 settings（如 os、compiler、arch、build_type）——而这些值，正是由你激活的 profile 决定的。
比如你执行：conan install . -pr=mygcc，那么 mygcc profile 中定义的 compiler=gcc、compiler.version=11、build_type=Release 就会原样注入到每个包的 self.settings，进而影响其 package_id 哈希值。
这意味着：同一份 conanfile.py，用不同 profile 构建，产出的二进制包 ID 完全不同，不会互相覆盖或复用。
Profile 中的 options 不影响 package_id，除非 recipe 显式使用
options（比如 shared=True、with_ssl=True）默认不进入 package_id 计算，除非你在 package_id() 方法里手动读取并纳入：
- 默认行为：只看
settings和requires的 major version（见下一条） - 如果你在
package_id()中写了self.info.options.shared = self.options.shared，那shared才会成为 ID 的一部分 - 但 profile 本身不能“强制”某个 option 进入 ID；它只是把
-o shared=True或profile里写的shared=True传给self.options，是否参与 ID，完全由 recipe 控制
Profile 没写全 settings，会导致 package_id 不稳定
如果 profile 缺少关键 settings 字段（比如漏了 compiler.libcxx），而 recipe 又声明了该 setting（settings = "os", "compiler", "arch", "build_type"），Conan 会在运行时补默认值（如 libstdc++11），但这个补全逻辑可能因 Conan 版本或环境而异。
后果是：
- 同一 profile 在不同机器上生成的
package_id可能不一致 - CI 环境和本地开发环境拉不到同一个二进制
- debug/release 切换时，
build_type若未显式设在 profile 里，容易被忽略
正确做法：profile 中显式写出所有 recipe 声明的 settings，哪怕值是默认的。例如：
[settings]<br>os=Linux<br>compiler=gcc<br>compiler.version=11<br>compiler.libcxx=libstdc++11<br>arch=x86_64<br>build_type=Release
Profile 不能绕过 recipe 的 validate() 或 package_id() 逻辑
profile 只是输入源，不是执行层。即使你在 profile 里写了 os=Windows，如果 recipe 中有：
def validate(self):<br> if self.settings.os == "Windows":<br> raise ConanInvalidConfiguration("Windows not supported")
那
conan create 依然会失败。
同理，profile 设了 build_type=Debug，但 recipe 的 package_id() 里写了：
if self.settings.build_type == "Debug":<br> self.info.build_type = "Release"
那最终生成的包 ID 仍等价于 Release 包——profile 提供的值被 recipe 主动覆盖了。
真正决定 package_id 的，永远是 self.info 的最终状态，而不是 profile 表面写了什么。
