conan 2.x 推荐在 requirements() 中为特定依赖设置 conf={"tools.build:force_reinstall": true}，仅强制重装该包而不影响其他依赖或破坏依赖图；命令行可用 --build=package/version 精准触发重建，但需版本完全匹配。
Conan 会默认跳过已安装的依赖包，除非你明确告诉它“这次必须重来”——没有全局开关能一键重刷某个包，但有精准、可靠、不破坏依赖图的方式。
用 conf 参数在 requires() 中强制重装单个依赖
这是 Conan 2.x 推荐且最干净的做法：只影响目标依赖，不影响其他节点，也不绕过 Conan 的解析逻辑。
- 在
conanfile.py的requirements()方法里，对需要重装的依赖显式传入conf={"tools.build:force_reinstall": True} - 例如：
self.requires("nanopb/0.4.6", conf={"tools.build:force_reinstall": True}) - 其他依赖（如
"fmt/10.2.1"）仍按常规流程走缓存匹配，不会被连带重装 - 该配置仅作用于当前 requirement，不污染 profile 或全局设置
用 --build=package_name 在命令行触发重构建
适用于临时调试或 CI 场景，无需改代码，但必须确保命令中指定的包名和版本完全匹配已安装项（包括用户/通道，如果用了的话）。
- 执行：
conan install . --build=nanopb/0.4.6 - 若包带通道，写全：
conan install . --build=nanopb/0.4.6@user/channel - 注意：
--build=missing不起作用——它只建缺失项；--build=outdated也无效，因为“是否过期”由 remote hash 决定，不是本地时间 - 此方式会重新下载源码、重新执行
build()和package()，但不会清除旧包，新包会覆盖同 package ID 的缓存项
为什么不用 conan remove + conan install？
手动删包再装看似直觉，但容易踩坑：
-
conan remove "nanopb/*"会删掉所有版本，可能误伤其他项目正在用的稳定版 - 删完后
conan install仍可能命中远程缓存中的二进制，未必触发本地重建 - 若依赖图中存在传递依赖（比如 A → B → nanopb），只删 nanopb 不保证 A/B 的 package ID 重算，链接行为可能不一致
- 没解决根本问题：你想要的是“这次构建必须用全新 nanopb”，而不是“让缓存变空”
真正关键的点是：Conan 的 package ID 是由 settings + options + recipe revision 共同决定的。如果你只是想换一种编译方式（比如加 -DDEBUG=ON），应该改 settings 或 options，而不是强行重装——否则 build_type 不一致时，链接会失败，而错误信息往往只报 cannot find -lnanopb，不提示维度错配。
