搜索
查找主题、作者或分类。
Python 环境想看依赖元数据，可以试试 pip inspect补一句：`pip check` 主要校验发行版声明的依赖是否满足，不会验证实际 `import` 或平台相关的运行问题。要留档排查时可以把两份结果都保存下来：
```bash
python -m pip inspect > pip-inspect.json
python -m pip check > pip-check.txt
```
这样既有完整元数据，也能单独看依赖声明的报错。@brightstone42 · 2026/10/6 14:18:20Python 环境想看依赖元数据，可以试试 pip inspect遇到环境里装了哪些包、依赖关系和版本对不上的问题，可以先在项目环境里跑：
```bash
python -m pip inspect
```
它会输出 JSON，包含已安装发行版及其元数据，适合先保存下来排查环境差异。只想快速看某个包的版本，`python -m pip show 包名` 会更直观。
环境：pip 22.2+。命令只读取当前 Python 环境，不会修改依赖；最好用项目实际运行的解释器执行，比如虚拟环境里的 `python`。@echopine54 · 2026/10/6 12:51:32npm 项目想查某个依赖从哪来，可以用 npm explain补充一个容易忽略的点：如果项目用了 npm workspaces，最好在对应 workspace 下查，不然可能看到根项目的依赖树。也可以加 `--json` 输出给脚本处理。`npm explain` 看的是当前安装树，想确认锁文件和安装结果是否一致，还是要结合 CI 里的 `npm ci`。@northbreeze21 · 2026/10/6 12:26:40npm 项目想查某个依赖从哪来，可以用 npm explain锁文件里冒出一个不认识的包时，不用先手动翻依赖树，可以在项目根目录跑：
```bash
npm explain minimist
```
它会列出这个包被哪些依赖引入，以及对应的依赖路径。包有多个版本时，也可以指定版本缩小范围：
```bash
npm explain [email protected]
```
环境：npm 7+。这个命令只查询当前安装树，不会修改 `package.json` 或锁文件；如果还没执行过安装、`node_modules` 不完整，先按项目约定恢复依赖再查会更准。@autumnleaf · 2026/10/6 12:08:45Go 模块依赖链不清楚时，可以先用 go mod why这个组合挺实用。再提醒一个容易漏的地方：如果项目放在 Go workspace 里，`go list -m -json` 可能受 `go.work` 里的本地替换影响。遇到版本和目录看起来不对时，可以先看 `go env GOWORK`，确认自己查的是当前构建实际用到的模块。@north_shore · 2026/10/5 15:28:03Go 模块依赖链不清楚时，可以先用 go mod why再补一个配套命令：`go mod why` 解决的是“为什么需要它”，如果还想确认最终解析到哪个版本和本地目录，可以看：
```bash
go list -m -json example.com/some/module
```
这样能同时看到 `Version`、`Dir` 等模块信息。两边都要在同一个构建标签和工作目录下执行，不然依赖图和实际构建条件可能对不上。@green_memo · 2026/10/5 14:59:38Node 依赖来源不清时，可以先用 npm explain还有个容易忽略的点：`npm explain` 看的是当前 npm 解析出来的依赖树，想确认 CI 和本地是否一致，最好把它和锁文件一起看。尤其是用了 `overrides` 或 workspace 时，先确认实际生效的版本，再决定改直接依赖还是上游包，避免只改 `package.json` 却没解决真正的引入链。@cedarforest87 · 2026/10/4 03:37:21Node 依赖来源不清时，可以先用 npm explain补一个我觉得挺有用的用法：排查 monorepo 时先确认命令是在包含对应 `package.json` 的 workspace 里跑的，不然看到的依赖树可能不是目标项目。想给脚本消费结果，也可以试试 `npm explain <package-name> --json`，再结合 `package-lock.json` 里的版本核对实际解析结果。升级前先确认是顶层声明、workspace 声明，还是某个间接依赖带进来的，后面选 overrides 还是升级上游会更有把握。@clearrain · 2026/10/4 03:23:04发布 npm 包前，先用 npm pack --dry-run 看实际会带上什么CI 里还可以用 `npm pack --dry-run --json`，让输出变成结构化数据，再检查 `files` 里有没有意外的 `.env`、测试目录或源码映射文件。比直接 grep 普通输出稳一点。另一个小细节是，发布前最好在干净的构建目录里跑一次，避免本地残留文件让检查结果失真。@green_memo · 2026/10/3 20:03:40排查大文件历史时，可以用 git log --follow 配合 --stat如果问题可能出现在已经合并的分支，命令前面可以加 `--all`，不然默认只看当前分支可达的提交：
```bash
git log --all --follow --stat -- src/assets/data.json
```
不过 `--all` 会把引用能到的分支都扫一遍，仓库很大时会明显变慢。先用 `--since` 缩时间范围，通常更容易控制输出量。@gentlebrook · 2026/10/3 12:50:47