brew deps 仅显示依赖层级而不标版本或冲突；实际需用 brew deps --installed --tree、--include-build 及 brew info 结合分析，配合 brew graph 或源码审查定位动态依赖问题。
brew deps 能看到依赖但不显示版本和冲突
直接运行 brew deps --tree <formula></formula> 只展示层级结构，不标出具体版本号，更不会提示哪个依赖被多个 formula 共用或存在版本冲突。比如装 ffmpeg 时它依赖 libvpx，而你本地已有通过 node 安装的 libvpx@1.12，brew deps 不会告诉你这可能引发链接冲突。
实际排查建议：
- 用
brew deps --installed --tree查看已安装包的真实依赖树（过滤掉未安装的可选依赖） - 对关键库加
--include-build看构建期依赖（比如cmake是否被某个 formula 的depends_on :build引入） - 配合
brew info <formula></formula>看其Depends on和Conflicts with字段（少数 formula 显式声明了冲突）
冲突常发生在 keg-only 包被多版本共用时
Homebrew 默认把有系统同名库的包（如 openssl、readline）设为 keg-only，不软链到 /usr/local。但当两个 formula 都需要 openssl，且一个要求 openssl@3、另一个只认 openssl@1.1，brew install 会静默跳过后者，导致编译失败——错误信息里往往只报 ld: library not found for -lssl，不提版本矛盾。
定位这类问题的关键操作：
- 查当前激活的版本：
brew --prefix openssl（返回路径），再ls -l $(brew --prefix openssl)/lib/libssl*看实际链接指向 - 强制重装并观察日志：
brew reinstall --debug --verbose openssl@1.1，留意输出中Conflicting files:或Would link:行 - 临时切换版本：
brew unlink openssl && brew link openssl@1.1，再测试构建是否通过
依赖树变更后 brew upgrade 可能破坏原有环境
Homebrew 不记录每个 formula 的“依赖快照”，brew upgrade 会按最新 Formula 文件里的定义重新解析依赖。比如某天 postgresql 把 icu4c 从 depends_on 改成 build_depends_on，你本地没重装过 postgresql，但 icu4c 被其他包升级到了 v74，而旧版 postgresql 二进制仍硬编码找 libicuuc.72.dylib，运行就报 dyld: Library not loaded: ... Reason: image not found。
应对策略有限但实用：
- 升级前先
brew outdated，重点关注带@版本号的包（如python@3.11），它们变动风险更高 - 用
brew pin <formula></formula>锁定关键基础依赖（如openssl@1.1、sqlite3），防止被连带升级 - 日常用
brew doctor检查Warning: Some installed formulae are deprecated or disabled.这类提示，背后常是依赖链断裂信号
真正需要依赖图谱时别硬扛 brew 原生命令
Homebrew 自身没有类似 pipdeptree 或 npm ls 的可视化依赖图工具。靠 brew deps + 手动递归查，遇到嵌套深、条件依赖多的包（如 llvm、rust）极易漏项。
更可行的替代方案：
- 用社区脚本：
brew tap-new homebrew/autotools && brew install homebrew/autotools/brew-graph，然后brew graph --installed --format=dot | dot -Tpng -o deps.png（需预装graphviz） - 对单个 formula 查全链：
brew deps --include-build --recursive <formula> | xargs -n1 brew info 2>/dev/null | grep -E '^(name|version|Depends on)'</formula> - 终极手段：进入
$(brew --repo)/Formula/<formula>.rb</formula>直接读 Ruby 源码，depends_on块里可能含:optional => true或if OS.mac?这类动态逻辑，命令行根本无法推断
依赖树不是静态快照，而是随 Formula 更新、本地安装状态、甚至 macOS SDK 版本实时变化的动态关系。最常被忽略的是：Homebrew 的“冲突”往往不在安装阶段报错，而在运行时因 dylib 符号缺失或 ABI 不兼容才暴露——这时候回溯比预防更耗时。
