直接用git diff -- 比对package.json或requirements.txt最准最轻量，不依赖外部工具；需指定提交而非仅用git diff，否则显示未暂存改动；加-M可识别重命名，避免误判。
比较两个提交中 package.json 或 requirements.txt 的差异
直接用 git diff 加路径是最准、最轻量的做法。它不依赖外部工具，也不需要改配置，适合 CI 脚本或快速排查。
常见错误是只跑 git diff 不带参数，结果看到的是工作区未暂存的改动，而非真正提交过的依赖变更。
-
git diff HEAD~1 HEAD -- package.json：对比上一个和当前提交的package.json -
git diff main feature/deps -- requirements.txt：对比main和feature/deps分支里requirements.txt的差异 - 如果文件被重命名或删除，加
-M参数（如git diff -M HEAD~2 HEAD -- pyproject.toml）能识别重命名，避免误判为“全删+全新”
为什么不能只靠 git status 或 IDE 内置比较？
git status 只告诉你“这个文件变了”，但看不出哪行删了 lodash@4.17.21、哪行加了 axios@1.7.0；IDE（如 VS Code）的 Git 面板默认只比对工作区与暂存区，而依赖升级往往是一次性 git add 后直接 commit，中间没有暂存状态可查。
更隐蔽的问题是：某些包管理器（如 npm install）会改写 package-lock.json 中时间戳或排序，导致 git diff 输出大量噪音。这时应优先比对 package.json，再针对性看 lock 文件关键段落。
跨仓库比较本地 node_modules 依赖树差异
这不是 Git 原生能力，但真实场景常有：比如想确认 A 项目升级后，webpack 实际解析出的子依赖版本是否和 B 项目一致。这时得绕过 Git，用工具导出依赖快照再比：
- 在两个项目根目录分别运行：
npx depcheck --json > deps-a.json和npx depcheck --json > deps-b.json - 然后用：
git diff --no-index deps-a.json deps-b.json - 或者更干净的方式：
npm ls --depth=0 --json | jq 'keys' | sort > deps-flat.json，再比这个扁平化列表
注意：npm ls 输出含符号链接和 peer 依赖逻辑，jq 处理前先确认是否要过滤掉 dev 依赖（加 --prod 参数）。
用 git difftool 可视化查看 pyproject.toml 差异时的坑
图形化工具（如 Beyond Compare、Meld）对结构化配置文件友好，但默认行为容易误导：
- Windows 下配置
bc5时，若路径含空格或中文，cmd行里没用双引号包裹$LOCAL和$REMOTE，会启动失败——错误信息通常静默消失，只弹个空白窗口 - VS Code 内置比较器对 TOML 格式支持弱，
[tool.poetry.dependencies]块里的换行缩进差异可能被忽略，建议用git difftool -t vimdiff临时验证 - 执行
git difftool HEAD~3 HEAD -- pyproject.toml时，若该文件在HEAD~3不存在，工具会报错退出；稳妥做法是先git show HEAD~3:pyproject.toml > tmp-old.toml，再手动比对
真正麻烦的不是命令怎么敲，而是搞清你到底想回答什么问题：是“谁改了依赖”，还是“改完之后实际装了什么”。前者看 Git 提交，后者得进容器或虚拟环境跑 pip freeze 或 npm list —— 这一步，Git 永远不会替你做。
