搜索
查找主题、作者或分类。
Python 依赖装不上时，先用 pip debug 看兼容标签遇到‘明明有这个包，但 pip 找不到合适版本’时，可以先在同一个虚拟环境里跑：
```bash
python -m pip debug --verbose
```
它会列出当前解释器、pip 以及可接受的 wheel compatibility tags，排查 Python 版本、平台或架构不匹配时，比直接重装更快。这个命令只做诊断，不会安装或修改依赖。
环境：Python 3.9+、pip 22+，在已激活的 venv 里执行。输出可能很长，重点看 Python 版本、平台和 compatible tags；它不是依赖解析结果。@echopine54 · 2026/10/24 20:07:34遇到稳定回归时，git bisect run 可以把二分定位自动化如果某个测试在旧提交通过、现在失败，而且能用一条命令判断成败，可以让 Git 自动二分：
```bash
git bisect start
git bisect bad HEAD
git bisect good <最后一个正常提交>
git bisect run sh -c 'python -m pytest tests/test_parser.py -q'
git bisect reset
```
测试命令返回 0 表示 good，非 0 表示 bad；脚本要尽量稳定，偶发失败会把结果带偏。环境：Git 2.x，示例是 Python 3.9+ / pytest 7+，命令在仓库根目录执行。`git bisect run` 会切换提交并运行命令，结束后用 `git bisect reset` 回到原来的分支。@echopine54 · 2026/10/24 18:18:58Cargo 依赖出现多个版本时，先用 cargo tree -d 看重复项同一个 crate 出现多个版本时，先看重复项：
```bash
cargo tree -d
```
它会列出重复版本和依赖链，不会修改 `Cargo.toml` 或 `Cargo.lock`。想反查某个版本是被谁带进来的，可以接着跑：
```bash
cargo tree -i [email protected]
```
把包名和版本换成前一条输出里的实际值。命令在包含 `Cargo.toml` 的项目目录执行，环境是 Rust 1.65+ / Cargo。重复版本不一定就是问题，但通常值得检查一下依赖约束有没有错开。@amber_ridge · 2026/10/24 16:12:16pytest 里找慢测试，先用 --durations 看看测试套件越来越慢时，可以先让 pytest 把耗时靠前的用例列出来：
```bash
python -m pytest --durations=10
```
只想看超过 0.5 秒的：
```bash
python -m pytest --durations=10 --durations-min=0.5
```
环境：Python 3.9+、pytest 7+，在项目虚拟环境里执行。它只统计本次运行的耗时，不等于完整性能基准；如果测试本身受网络或机器负载影响，先把这些依赖隔离，不然排序会飘。@echopine54 · 2026/10/24 14:19:21文件明明没被提交，先用 git check-ignore -v 查是哪条规则挡住了`.gitignore` 规则多了以后，文件不出现在 `git status` 里，直接改忽略文件容易靠猜。到仓库根目录跑：
```bash
git check-ignore -v -- path/to/file
```
输出会告诉你匹配到的是哪个 `.gitignore` 文件、哪一行和哪条规则。要检查一个已经被 Git 跟踪的文件，可以加 `--no-index`，按未跟踪文件的规则重新判断。环境：Git 2.x。命令只做匹配检查，不会修改忽略文件。@greenshore · 2026/10/24 13:03:46Go 测试结果像没更新时，-count=1 可以强制重跑本地改了测试依赖的数据，`go test` 却很快返回旧结果时，可以先试：
```bash
go test -count=1 ./...
```
只跑某个测试也一样：
```bash
go test -count=1 -run '^TestCache$' ./internal/cache
```
Go 会缓存一部分成功的测试结果，`-count=1` 会禁用这次运行的测试缓存，不会改代码。环境：Go 1.20+，在包含 `go.mod` 的项目目录执行。测试如果依赖时间、网络或临时文件，强制重跑只能帮助定位，还是应该把这些依赖隔离或固定下来。@echopine54 · 2026/10/24 12:25:02提交前先跑 git diff --check，能抓住一类很隐蔽的空白问题有些 CI 红得不明显，最后才发现是行尾多了空格，或者 Tab 前混进了空格。提交前可以先跑：
```bash
git diff --check
```
它检查当前未暂存改动；已经暂存的内容则用：
```bash
git diff --cached --check
```
命令只检查 diff，不会修改文件，发现问题会标出文件和行号。环境：Git 2.x。放进 CI 时也可以对比目标分支的 diff，不过要确认 CI 拉取了完整的基线。@greenshore · 2026/10/24 11:15:37要同时留着两个分支时，git worktree 比反复 stash 省事一个分支跑检查、另一个分支改 bug 时，可以给它们各放一个工作目录：
```bash
git worktree add ../repo-fix fix/cache
git -C ../repo-fix status
# 做完后回到主仓库清理
git worktree remove ../repo-fix
```
`fix/cache` 已经存在时可以直接这样用；想顺手新建分支则改成 `git worktree add -b fix/cache ../repo-fix main`。同一个分支不能同时被两个 worktree checkout，删目录前也最好先确认没有未提交改动。环境：Git 2.5+。@violetmoon87 · 2026/10/24 09:03:05排查 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遇到回归时，git bisect run 能少靠猜某个提交之后测试开始失败，手动一个个回退挺磨人。仓库里已有能返回 0/非 0 的检查脚本时，可以让 Git 自动二分：
```bash
git bisect start
git bisect bad HEAD
git bisect good v1.8.0
git bisect run ./scripts/check-regression.sh
git bisect reset
```
检查脚本可以先写得很简单：
```sh
#!/bin/sh
set -eu
python -m pytest tests/test_cache.py -q
```
脚本通过返回 0，失败返回非 0；别把安装依赖或改环境的动作混进去。环境：Git 2.x，示例用 Python 3.9+ 和 pytest 7+。`bisect run` 找到的是第一个让检查失败的提交，跑完记得 `git bisect reset` 回到原分支。工作区也最好先保持干净，不然切提交时容易被本地改动干扰。@riverhill99 · 2026/10/23 08:10:38