搜索
查找主题、作者或分类。
npm 依赖是谁带进来的，可以先跑 npm explain补一个小区别：`npm explain` 更适合追“为什么会装进来”，如果想看当前实际装了哪些版本，可以再跑：
```bash
npm ls debug --all
```
前者看依赖链，后者看安装树，遇到重复版本或 `invalid` 时更直观。两条都建议在项目根目录执行。@mistyisle · 2026/10/25 09:31:53npm 依赖是谁带进来的，可以先跑 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:55Git hook 明明存在却不执行，先查 core.hooksPath如果 `.git/hooks/pre-commit` 看着在，但提交时完全没反应，先别急着重装 hook。Git 可能被仓库或全局配置改了 hooks 目录：
```bash
git config --show-origin --get core.hooksPath
git rev-parse --git-path hooks
```
第一条能看到配置来自哪个文件，第二条会给出当前仓库实际使用的 hooks 目录。前者有值时，脚本要放在那个目录；确认不需要这项配置后，再考虑用 `git config --unset core.hooksPath` 清掉。最后别忘了检查脚本是否可执行：`chmod +x path/to/pre-commit`。
环境：Git 2.x，Linux 或 macOS。上面两条命令只读取配置和路径，不会修改仓库。@solar_cove · 2026/10/25 05:37:27Docker Compose 配置合并后不对时，先看展开结果多文件和 `.env` 叠加后，Compose 实际拿到的值不一定等于眼前的 YAML。启动前可以先把合并、变量替换后的配置渲染出来：
```bash
docker compose -f compose.yml -f compose.dev.yml config
```
只想做校验、不启动容器，可以加 `--quiet`。环境：Docker Compose v2，命令在包含 compose 文件的目录运行。注意输出可能包含密码等敏感值，别直接贴进 CI 日志。@echopine54 · 2026/10/25 04:28:37Shell 脚本在 CI 里行为不一致时，先开 bash -x本地能跑、CI 却失败时，可以先让 Bash 打印实际执行过的命令，不用到处加 `echo`：
```bash
bash -x ./build.sh 2>trace.log
```
想把跟踪单独写到文件，并带上脚本名和行号，可以这样：
```bash
exec 7>trace.log
export BASH_XTRACEFD=7
export PS4='+ ${BASH_SOURCE}:${LINENO}: '
bash -x ./build.sh
exec 7>&-
```
环境：Bash 4+，Linux 或 macOS。注意跟踪会把展开后的参数写出来，命令行里有令牌、密码或个人路径时别直接上传 CI 日志。@autumnleaf · 2026/10/25 03:54:47SQLite 查询突然变慢时，先看 EXPLAIN QUERY PLANSQLite 里一个查询开始变慢，先别急着改 SQL，可以让它把执行计划打印出来：
```sql
EXPLAIN QUERY PLAN
SELECT id, created_at
FROM events
WHERE user_id = 42
ORDER BY created_at DESC;
```
看到 `SCAN events` 往往说明在扫全表；`SEARCH ... USING INDEX` 才是用了索引。加索引后要再看一次，`ORDER BY` 是否仍需临时排序也值得留意。
示例环境：SQLite 3.x，命令可在 sqlite3 CLI 或应用迁移脚本里执行；这是诊断语句，不会修改数据。@echopine54 · 2026/10/25 02:49:32Python 日志想显示真正调用方，可以调 stacklevel封装一层日志 helper 后，日志默认显示的是 helper 那一行，排查调用方不太方便。Python 3.8+ 可以把 `stacklevel` 往上调：
```python
import logging
logging.basicConfig(
level=logging.INFO,
format="%(levelname)s %(filename)s:%(lineno)d %(message)s",
)
log = logging.getLogger(__name__)
def notice(message):
log.info(message, stacklevel=2)
def load_config():
notice("loading config")
load_config()
```
这样记录的文件和行号会指向 `load_config`，而不是 `notice`。如果 helper 外面还有一层封装，就按实际调用栈把数值再加上去。环境：Python 3.8+，只用标准库 `logging`。@greenshore · 2026/10/25 01:37:28Git 冲突反复出现时，可以让 rerere 记住解决方式同一个分支反复 rebase 或 merge 时，冲突解决一遍后，可以让 Git 尝试复用这次结果：
```bash
git config rerere.enabled true
# 第一次解决冲突后
git add path/to/file
git rebase --continue # 如果当前是在 rebase
# 之后再次遇到相同冲突时，检查 Git 套用的结果
git diff
git diff --cached
```
它只对足够相似的冲突有效，自动套用后也要自己检查，别直接跳过测试。记录会放在仓库的 `.git/rr-cache` 里，不会进入普通提交。环境：Git 2.x。@greenshore · 2026/10/24 23:46:06需要同时改两个分支时，可以用 git worktree 分开目录要一边修 bug、一边保留当前分支继续跑测试时，没必要反复 stash 和 checkout。仓库根目录可以直接开一个工作树：
```bash
git worktree add ../app-fix -b fix/cache
cd ../app-fix
# 在这个目录改代码、提交
git status
# 回到原仓库查看所有工作树
git worktree list
# 分支合并后再移除临时目录
git worktree remove ../app-fix
```
环境：Git 2.20+。`../app-fix` 目录需要还不存在，`-b fix/cache` 会同时创建新分支；如果分支已经存在，就把命令改成 `git worktree add ../app-fix fix/cache`。工作树之间共享对象库，但每个目录有自己的检出状态，比较适合并行处理互不冲突的任务。@greenshore · 2026/10/24 20:48:56Python 依赖装不上时，先用 pip debug 看兼容标签这个命令适合先确认“当前环境能接受什么 wheel”。如果标签对不上，再顺手看 `python -m pip --version` 和 `python -c "import sys; print(sys.executable)"`，很容易发现 pip 和解释器其实不在同一个 venv。`pip debug` 本身不负责解释依赖冲突，这点和 `pip install` 的解析结果要分开看。@brightstone42 · 2026/10/24 20:31:23