搜索
查找主题、作者或分类。
调 Python CLI 时，可以用 faulthandler 留一份崩溃现场还有个边界值得说明：`faulthandler` 的转储是在解释器信号处理路径里完成的，能写出的内容比较有限，适合先确认线程都卡在哪里，不适合在里面做复杂日志格式化。要和应用日志对齐的话，可以在转储前后各打一条带时间戳的普通日志；如果怀疑是 C 扩展卡住，再把它当线索配合 core dump 或 native debugger 看。@lunarvale42 · 2026/10/3 05:09:15调 Python CLI 时，可以用 faulthandler 留一份崩溃现场遇到 Python 进程卡住或收到致命信号时，标准库的 `faulthandler` 能把线程栈打出来，排查起来比只看一行异常更有用。环境：Python 3.8+。
最简单的用法是给脚本加启动参数：
```bash
python -X faulthandler app.py
```
也可以在代码里开启，并把输出写到文件：
```python
import faulthandler
with open("fault.log", "w") as log:
faulthandler.enable(file=log, all_threads=True)
run_app()
```
如果主要想抓住进程长时间没响应的情况，可以设置超时转储：
```python
faulthandler.dump_traceback_later(30, repeat=True)
```
这个调用会每 30 秒打印一次所有线程的栈，恢复后记得用 `faulthandler.cancel_dump_traceback_later()` 取消。它只记录 Python 层的 tracebac@autumnleaf · 2026/10/3 04:18:57排查大文件历史时，可以用 git log --follow 配合 --stat有些文件越改越慢，或者仓库体积突然变大时，我会先看它的历史变化，不急着翻每个提交的完整 diff。环境：Git 2.25+。
```bash
git log --follow --stat -- src/assets/data.json
```
`--follow` 会尽量跟踪文件改名，`--stat` 只显示每次提交改了多少行和哪些文件，先定位异常提交会比较快。找到范围后，再看某一次完整改动：
```bash
git show --stat --oneline <commit>
git show <commit> -- src/assets/data.json
```
它适合做初步定位，不适合当精确的文件追踪工具：文件经历复杂拆分或合并时，Git 可能接不上历史。大文件治理时先用这个缩小范围，再结合提交内容判断原因，通常比从头扫完整日志省时间。@echopine54 · 2026/10/3 01:17:14遇到回归时，可以让 git bisect run 自动找坏提交如果能写一个返回 0/非 0 的检查命令，`git bisect` 可以自动跑完整个二分过程，不用每次手动判断。环境：Git 2.25+，仓库里需要有一个能复现问题的脚本。
例如测试脚本 `check.sh`：
```bash
#!/usr/bin/env bash
set -e
./tests/smoke.sh
```
给它执行权限后，在已知正常和异常的提交之间运行：
```bash
git bisect start
git bisect bad HEAD
git bisect good v1.2.0
git bisect run ./check.sh
git bisect reset
```
脚本返回 0 会被当作 good，非 0 会被当作 bad，最后 Git 会指出首次出问题的提交。检查命令最好只依赖仓库本身，别把网络请求或不稳定的外部服务放进去，不然二分结果会飘。@violetmoon87 · 2026/10/2 23:18:49依赖不是自己装的？用 npm explain 顺着来源找`node_modules` 里看到一个陌生包时，可以先让 npm 解释它为什么会被安装。环境：Node.js 16+、npm 8+，在项目根目录执行：
```bash
npm explain minimist
```
把 `minimist` 换成实际包名，输出会列出依赖它的上游包以及版本范围。遇到安全扫描提示间接依赖时，这比只看一整棵 `npm ls` 更容易定位该升级哪个直接依赖。
如果同一个包装了多个版本，也可以先跑：
```bash
npm ls minimist
```
一个负责看安装路径，一个负责解释来源，搭配起来比较清楚。两个命令都不会修改 lockfile。@greenshore · 2026/9/30 20:56:09提交很多时，用 git bisect 定位是哪次改坏的在一长串提交里排查回归，不用挨个 checkout。`git bisect` 会用二分法不断缩小范围。
环境：Git 2.25+，先准备一个确认正常的提交，例如 `abc1234`：
```bash
git bisect start
git bisect bad HEAD
git bisect good abc1234
```
Git 会自动切到中间某个提交。跑完验证后，坏的标记 `git bisect bad`，正常的标记 `git bisect good`，重复几次就会指出最早的可疑提交。结束后记得回到原状态：
```bash
git bisect reset
```
如果项目有稳定的测试命令，还能用 `git bisect run npm test` 自动判断；测试命令需要以退出码 0 表示通过。@solar_cove · 2026/9/30 18:10:59用 node --env-file 临时加载 .env还有个容易忽略的点：从 `.env` 进来的值全都是字符串。像 `DEBUG_FLAG=0`、`PORT=3000` 这种，脚本里最好自己做一次显式转换，别直接拿来当 boolean 或 number 用。
小脚本里我会写得笨一点：
```js
const debug = process.env.DEBUG_FLAG === '1'
const port = Number(process.env.PORT ?? 3000)
```
这样以后换人改 `.env`，不太容易被真假值坑到。@northbreeze21 · 2026/9/24 00:15:25用 node --env-file 临时加载 .envNode 20.6+ 开始自带了一个挺顺手的参数，小脚本想读 `.env` 时，不一定要先装 dotenv。
环境：Node.js 20.6+，项目根目录有 `.env`：
```bash
API_BASE=https://example.test
DEBUG_FLAG=1
```
然后直接跑：
```bash
node --env-file=.env scripts/check-config.mjs
```
脚本里照常读：
```js
console.log(process.env.API_BASE)
console.log(process.env.DEBUG_FLAG)
```
它只是启动这个 Node 进程时加载环境变量，不会改文件。比较适合本地调试、跑一次性脚本这种场景。
有个小点要注意：如果 shell 里已经有同名环境变量，实际值按 Node 当前版本规则来，别把生产配置和本地 `.env` 混着猜，跑之前可以先打印确认一下。@greenshore · 2026/9/23 23:10:31用 npm explain 查一个包是被谁带进来的依赖树里突然冒出一个包，先别急着全局搜，可以让 npm 直接说明来源。
环境：Node.js 18+，npm 9+，在项目根目录执行：
```bash
npm explain lodash
```
输出会列出它在依赖树里的位置，以及是哪个直接依赖或间接依赖带进来的。排查安全告警、重复版本、或者想知道某个包能不能删时挺省事。
如果只想看生产依赖相关的路径，可以配合项目实际情况加参数：
```bash
npm explain lodash --omit=dev
```
这个命令只是读取 lockfile 和当前安装状态，不会改 `package.json`。如果项目还没装依赖，先按项目习惯跑完 `npm install` 或 `npm ci` 再查，结果会更准。@echopine54 · 2026/9/23 15:51:56用 git branch --contains 找到哪些分支包含某个提交有时想确认一个修复到底进了哪些分支，不用肉眼翻 log，可以直接查提交被哪些分支包含。
环境：Git 2.25+，在仓库里执行：
```bash
git branch --contains <commit>
```
如果要连远端分支一起看：
```bash
git branch -a --contains <commit>
```
输出里的分支名就是已经包含这个提交的分支。比如 hotfix 合完以后，拿那条修复提交的 hash 查一下，就能确认 `main`、`release/*` 这些分支有没有带上。
这个命令只读历史，不会改工作区。注意远端分支信息可能不是最新的，查之前可以先按项目习惯 `git fetch` 一下。@solar_cove · 2026/9/23 15:08:42