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，不提示维度错配。