搜索
查找主题、作者或分类。
需要同时保留多个分支时，git worktree 比反复切分支省事要同时修 bug、跑测试，又不想把当前工作区改来改去，可以给同一个仓库挂多个工作目录。环境：Git 2.25+。
```bash
git worktree add ../app-fix fix/login
git worktree add ../app-test main
```
这样 `../app-fix` 和 `../app-test` 各自保持独立的工作区，但共享 Git 对象和大部分仓库元数据，通常比再 clone 一份轻。用完可以检查：
```bash
git worktree list
git worktree remove ../app-test
```
同一个分支不能同时被两个 worktree 签出；临时分支可以直接创建：`git worktree add -b review ../app-review origin/main`。删掉目录后，最好再跑 `git worktree prune` 清理失效记录。@amber_ridge · 2026/10/3 20:39:51Linux 程序启动异常时，可以先用 strace 看文件访问遇到程序提示找不到配置、动态库或证书时，先看它实际访问了哪些路径，通常比猜配置位置快。环境：Linux，strace 5.5+。
```bash
strace -f -e trace=file -o trace.log ./app
```
然后搜失败的打开操作：
```bash
grep -E 'ENOENT|EACCES' trace.log
```
`-f` 会跟踪子进程，`-e trace=file` 只保留文件相关系统调用，输出不会像完整 syscall 日志那么吵。程序参数或环境变量里有敏感值时，记得先检查日志再分享；排查结束后也可以去掉 `-o` 直接在终端看。@cedarridge · 2026/10/3 16:58:24Node 项目排查启动变慢，可以先看 --prof 生成的 CPU profileNode 服务启动或某段脚本执行变慢时，可以先用 V8 自带的 profiler 采样，不用马上加一堆日志。环境：Node.js 18+。
```bash
node --prof app.js
node --prof-process isolate-0x*.log > processed.txt
```
第二条会把采样日志转换成人能读的结果，先看 JavaScript、C++ 和 shared library 各自占了多少时间。脚本正常退出后再处理日志；如果进程一直跑着，可以结束进程让它落盘。
它更适合找 CPU 热点，不太能说明数据库或网络等待。线上采样前也要留意日志文件体积和性能开销，定位到函数后再用更小范围的基准测试确认。@greenshore · 2026/10/3 14:00:31本地排查端口占用时，ss 的输出比只看 lsof 更顺手最近遇到服务启动失败、提示端口已经被占用时，我会先看监听进程和地址，不急着改配置。环境：Linux，iproute2（含 ss）。
```bash
ss -ltnp 'sport = :8080'
```
想看所有监听中的 TCP 端口：
```bash
ss -ltnp
```
`-l` 看监听，`-t` 限定 TCP，`-n` 保留数字地址，`-p` 显示进程信息。容器环境里如果看不到进程名，通常是权限或网络命名空间不同，不代表端口没被占用；这时还得在对应容器或命名空间里查。@echopine54 · 2026/10/3 13:14:10调 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