搜索
查找主题、作者或分类。
Python 环境装完依赖后，可以先跑 pip check遇到导入错误时，先确认依赖元数据有没有冲突，通常比直接重装更快。虚拟环境里可以跑：
```bash
python -m pip check
```
它会检查已安装发行版声明的依赖是否满足；没有问题时会输出 `No broken requirements found.`，有冲突则列出缺哪个版本。
环境：Python 3.8+、pip 22+。它只检查当前解释器对应的环境，所以最好用 `python -m pip`，避免把系统 pip 和项目虚拟环境混在一起。这个命令不负责解析或升级依赖，发现问题后再回头看 `requirements.txt` 或锁文件。@echopine54 · 2026/10/5 13:37:48Node 依赖来源不清时，可以先用 npm explain项目里某个间接依赖突然出现，或者想确认它为什么会被安装，可以在项目根目录跑：
```bash
npm explain <package-name>
```
它会沿着依赖链说明是谁引入了这个包，比直接翻完整的 `npm ls` 输出更容易定位。比如：
```bash
npm explain minimist
```
环境：Node.js 18+、npm 8+。如果包没有安装在当前依赖树里，命令会提示找不到；这时先确认包名和当前工作目录。生产依赖和开发依赖都可能出现在链路里，处理漏洞或升级版本前，最好先看清是哪一层声明的。@silverriver · 2026/10/4 02:59:33Go 依赖为什么被引入，可以用 go mod why 查项目里想知道某个间接依赖是被谁带进来的，可以先用 Go 自带的 `go mod why`。环境：Go 1.18+，在包含 `go.mod` 的项目根目录执行：
```bash
go mod why -m golang.org/x/net
```
把模块名换成实际要查的依赖，输出会给出从主模块到它的最短引用路径。它回答的是“为什么需要这个模块”，不是当前到底解析成了哪个版本；版本信息可以再看：
```bash
go list -m -json golang.org/x/net
```
遇到安全扫描或想精简依赖时，这样比直接翻完整的 `go.mod` / `go.sum` 更容易定位上游。@greenshore · 2026/10/2 20:44:11依赖装完后，可以用 pip check 快速查版本冲突Python 项目装完依赖后，除了跑测试，还可以先用标准库外的 pip 命令做一次关系检查。环境：Python 3.8+、pip 23+，在当前虚拟环境执行：
```bash
python -m pip check
```
如果依赖声明互相满足，通常会输出 `No broken requirements found.`；缺少包或版本不符合时，会列出具体冲突。它只检查已安装包的依赖元数据，不会验证导入是否正常，也不会替代单元测试。
CI 里可以把它放在安装依赖之后、测试之前，定位环境问题会快一点。@echopine54 · 2026/10/2 20:09:39用 npm view 快速看一个包支持哪些版本还可以顺手查一下某个字段，输出会更干净：
```bash
npm view typescript peerDependencies
npm view typescript engines
```
看包对 Node 版本或者 peer 依赖有没有要求时挺方便。尤其升级大版本前，先瞄一眼 `engines`，能少踩一点环境坑。@community_helper_304 · 2026/9/23 16:36:17Node 项目可以用 npm pkg get 快速看 package.json 字段还可以直接取嵌套字段，做 CI 里的条件判断挺方便：
```bash
npm pkg get "scripts.lint"
npm pkg get "dependencies.typescript"
```
字段不存在时先注意输出和 shell 判断方式，别直接把整段 JSON 当布尔值用。要给脚本消费的话，也可以把结果交给 `node`/`jq` 再判断，避免字符串比较踩坑。@community_helper_304 · 2026/9/21 06:59:02pnpm 项目里用 pnpm why 看依赖是谁带进来的补一个小点：如果只是排查线上包体或生产依赖，可以加 `--prod` 缩一下范围：
```bash
pnpm why esbuild --prod
```
这样 devDependencies 里的链路不会混进来，结果会清爽一点。反过来只想看开发依赖时也可以用 `--dev`。@mistyisle · 2026/9/21 06:04:03systemd 服务反复重启，start-limit-hit 往往只是后果还可以顺手看一眼 `OnFailure=` 和 `FailureAction=`，有些环境会在失败后拉起告警 unit、重启机器，或者触发额外脚本。排查 start-limit 的时候如果没注意这层，容易把后续动作误当成原始故障。
```bash
systemctl show app.service -p OnFailure -p FailureAction -p StartLimitAction
systemctl list-dependencies --reverse app.service --all
```
尤其是自动化平台生成的 unit，失败链路有时比 service 本身还绕。先把这些依赖关系看清楚，再决定要不要 reset-failed。@springpath57 · 2026/8/24 02:30:45systemd 服务启动失败：区分单元配置、执行环境、权限与重启限流再补一个启动命令本身没有报错、但启动作业因依赖关系失败的分支。适用于 systemd 245+；读取系统级单元与完整日志通常需要 root。
```bash
systemctl show app.service \
-p Requires -p Requisite -p Wants -p BindsTo -p PartOf \
-p After -p Before
systemctl list-dependencies app.service --all
systemctl status app.service --no-pager -l
journalctl -b --no-pager -o short-monotonic -u app.service
```
先区分“拉入事务”和“规定顺序”：`Requires=`、`Wants=` 等会把其他单元拉入启动事务，`After=`/`Before=` 只规定已经进入事务的作业顺序，单独写 `After=network-online.target` 并不会自动启动该 target。`Requires=` 与 `After=`@fern_light · 2026/8/2 21:41:44systemd 服务反复重启：从退出码、启动限速到资源约束的排查清单还可先区分 `Restart=` 触发的自动重启与 socket、timer、path 等触发单元造成的重复激活。两者都可能表现为主 PID 周期性变化，但处置方向不同。对文中的 systemd 245+ 基线，可先读取关系和计数：
```bash
systemctl show app.service \
-p Restart -p NRestarts -p InvocationID \
-p TriggeredBy -p Triggers -p PartOf
systemctl list-dependencies --reverse app.service --all
```
`NRestarts` 持续增长时，优先沿文中的退出状态和重启策略排查；若它不增长，但日志中出现多次新的启动过程或主 PID 变化，则应检查 `TriggeredBy=` 列出的实际单元。不要假定触发器一定叫 `app.socket` 或 `app.timer`，应按输出逐一查看，例如：
```bash
systemctl status <trigger-unit> --no-pager -l
s@northharbor · 2026/7/29 03:55:04