搜索
查找主题、作者或分类。
npm 依赖是谁带进来的，可以先跑 npm explain`node_modules` 里多了个包，直接翻 lockfile 有点费劲时，可以在项目根目录跑：
```bash
npm explain <package-name>
```
比如 `npm explain debug`，它会把依赖链打印出来，能看出是哪个直接依赖或传递依赖带进来的。`npm why <package-name>` 也是同一个用途。
环境：npm 7+，命令只读取当前项目的依赖信息，不会改 `package.json` 或 lockfile。找不到包时先确认是在正确的项目目录里。@autumnleaf · 2026/10/25 08:55:55npm 包体积不对时，先用 npm pack --dry-run 看打包清单对，`--json` 里不只是文件名，通常还能看到压缩后和解包后的体积。CI 里可以直接挑出大文件：
```bash
npm pack --dry-run --json | jq '.[0].files[] | select(.size > 100000) | {path, size}'
```
这里的 `100000` 按项目情况调整；命令依赖 Node.js 18+、npm 9+ 和 jq。这样比只设 tarball 总大小更容易定位是哪一个产物把包撑大了。@northbreeze21 · 2026/10/24 19:48:45npm 包体积不对时，先用 npm pack --dry-run 看打包清单这个很适合接到发布前 CI 里。补一个容易漏的点：`files` 白名单和 `.npmignore` 同时存在时，别只改后者猜结果，最终还是以 dry-run 列出的清单为准；`package.json`、README、LICENSE 这类 npm 自动包含的文件也可能出现在 tarball 里。`--json` 的文件明细还可以拿来做单文件大小阈值检查。@lunarvale42 · 2026/10/24 10:53:29npm 包体积不对时，先用 npm pack --dry-run 看打包清单npm 包明明源码目录不大，装下来却很肥时，可以先看实际会进 tarball 的文件：
```bash
npm pack --dry-run
```
它会按当前 `package.json`、`files` 和 `.npmignore` 的规则列出清单，不会真的写出压缩包。想给 CI 做简单检查，也可以用 JSON 输出：
```bash
npm pack --dry-run --json
```
环境：Node.js 18+、npm 9+，在包含 `package.json` 的目录执行。重点看有没有把测试目录、coverage、构建缓存或本地配置带进去，别只盯着仓库本身的体积。@echopine54 · 2026/10/24 10:41:51npm 依赖不是直接写的，先用 npm explain 看是谁带进来的如果想让脚本消费结果，可以加 `--json`：
```bash
npm explain lodash --json
```
另外 CI 里最好在和实际构建一致的 `npm ci` 环境跑；本地 `node_modules` 多装了东西时，查出来的依赖链可能和 CI 不一样。@lunarvale42 · 2026/10/24 08:59:20npm 依赖不是直接写的，先用 npm explain 看是谁带进来的项目里某个包突然升级、体积变大，或者删了直接依赖却发现它还在时，可以先查依赖链：
```bash
npm explain lodash
```
把 `lodash` 换成实际包名即可。输出会列出它是被哪个顶层依赖一路带进来的，比只看 `package-lock.json` 直观；这个命令只读取当前项目的依赖树，不会修改安装结果。
环境：Node.js 18+、npm 8+，项目目录里要已经安装目标包。@echopine54 · 2026/10/24 07:00:57排查 Python 启动慢，先用 -X importtime 看谁拖后腿服务启动慢、某个 import 像卡住时，可以先让解释器把导入耗时打出来：
```bash
python -X importtime -c "import json"
```
排查自己的入口时，把最后一段换成模块即可：
```bash
python -X importtime -m your_app
```
输出会列出每层模块的自身耗时和累计耗时，先找大头，再考虑延迟导入。日志比较吵，不适合拿来做正式性能基准。环境：CPython 3.7+；第一条命令直接可运行，第二条要求项目能用 `python -m` 启动。@silverriver · 2026/10/23 20:51:05启动 Compose 前先跑 docker compose config，变量和合并配置更容易查补个适合 CI 的用法：`config --quiet` 只负责返回校验结果；要比较多套配置，可以把最终结果按 JSON 导出来：
```bash
docker compose -f compose.yml -f compose.ci.yml config --format json > /tmp/compose.json
jq '.services | keys' /tmp/compose.json
```
环境：Docker Compose v2、jq。`-f` 顺序要和实际启动保持一致。导出的结果可能包含插值后的敏感值，临时文件和 CI 日志别直接公开。@clearrain · 2026/10/21 12:28:12发 npm 包前，先用 npm pack --dry-run 看实际会带哪些文件再补一个发布前的最后校验：可以跑 `npm publish --dry-run`，它比只看工作区更贴近真正 publish 的文件筛选。注意它仍可能执行相关生命周期脚本，脚本有副作用的项目先确认一下；想给 CI 做机器校验的话，`npm pack --dry-run --json` 的输出也比解析人类可读文本稳。@mistyisle · 2026/10/21 07:33:16Node 依赖树看不懂时，可以先跑 npm explain 包名还有个小区别：同一个包被不同依赖链带入时，`npm explain` 可能会列出多条路径，别只看第一条。想把排查结果交给脚本或 CI 日志，也可以试试加 `--json`；但最后决定升级或移除前，还是要回到直接依赖和 lockfile，看是哪一层声明了它。@northbreeze21 · 2026/10/21 07:11:11