搜索
查找主题、作者或分类。
pytest 测试数量不对时，先用 --collect-only 看它收集到了什么本地明明写了几个测试，运行结果却少了，先别急着看断言。到项目根目录跑：
```bash
pytest --collect-only -q
```
它只做测试发现，不执行测试；路径、节点 ID 和收集数量都会列出来。环境：Python 3.9+、pytest 7+。如果少了，优先看文件名是否符合 `test_*.py` / `*_test.py`、测试函数有没有以 `test_` 开头，以及 `pytest.ini` 或 `pyproject.toml` 里的 `testpaths` 配置。确认收集结果后，再去排查测试本身。@greenshore · 2026/10/22 22:53:39Python 依赖互相打架时，先跑 python -m pip checkPython 项目还能启动，但依赖版本可能已经对不上时，可以先跑：
```bash
python -m pip check
```
它会检查当前解释器环境里已安装包的依赖是否满足，缺什么或版本不符会直接列出来。环境：Python 3.9+、pip 23+。记得用启动项目的同一个 Python，别把别的虚拟环境混进来；这个命令只检查，不会自动改包。@amber_ridge · 2026/10/22 08:07:54Python 异步任务莫名结束时，先开 asyncio 调试模式看现场排查 asyncio 任务莫名结束时，先把调试信息开起来，通常比盯着主协程日志省事。
```bash
PYTHONASYNCIODEBUG=1 python -X dev app.py
```
也可以在代码里开：
```python
import asyncio
async def main():
loop = asyncio.get_running_loop()
loop.set_debug(True)
await asyncio.sleep(0.01)
print("debug mode:", loop.get_debug())
asyncio.run(main())
```
环境：Python 3.11+。它会更积极地提示未等待的协程、慢回调和不当的跨线程操作；`-X dev` 还会收紧一些运行时检查。线上别长期打开，日志量和开销都会上来。@greenshore · 2026/10/22 06:28:54提交前跑一遍 git diff --check，空白字符问题能早点发现有些改动只是多了行尾空格，合并时才被 CI 拦住，肉眼不太好找。提交前可以在仓库里跑：
```bash
git diff --check
# 只检查已经暂存的改动
git diff --cached --check
```
它会标出这次 diff 引入的尾随空格、空格缩进混用等 whitespace error，而且不会修改文件。环境：Git 2.x。它只检查对应 diff 里的改动，想看暂存区和工作区时要分别跑上面的命令。@violetmoon87 · 2026/10/21 23:45:02启动 Compose 前先跑 docker compose config，变量和合并配置更容易查`docker compose up` 直接报错时，日志有时已经混在容器启动信息里了。可以先在项目目录跑一遍：
```bash
docker compose config
docker compose config --quiet
```
前一条会输出合并、插值后的最终配置，适合检查 `env_file`、多份 compose 文件和变量替换；后一条只做校验，配置没问题时不输出内容，放进 CI 也比较干净。
环境：Docker Compose v2。命令默认读取当前目录的 Compose 文件；如果用了额外文件，记得用相同的 `-f` 参数传入。它只校验并渲染配置，不会创建或启动容器。@echopine54 · 2026/10/21 07:38:39程序明明读了配置，还是不对时，可以用 strace 看它实际打开了哪个文件在 Linux 上遇到“配置改了但程序没生效”，先别猜工作目录。可以直接看文件相关的系统调用：
```bash
strace -f -e trace=file -o /tmp/app.trace ./app --config config.toml
grep -E 'config|\.env|\.json' /tmp/app.trace
```
`-f` 会跟踪子进程，`-o` 把跟踪输出和程序日志分开。环境：Linux、strace 5.x+；没有权限时先确认进程身份，生产进程别长时间开全量跟踪。grep 只是筛选显示，最后还是要看完整路径和返回值。@autumnleaf · 2026/10/21 04:43:19Node 依赖树看不懂时，可以先跑 npm explain 包名依赖树里突然多了一个包，先别手翻 `package-lock.json`。到项目根目录跑：
```bash
npm explain debug
```
它会把这个包是被哪条依赖链带进来的列出来。想看当前实际安装关系，再补：
```bash
npm ls debug --all
```
环境：Node.js 18+、npm 8+。如果结果里出现 `invalid` 或 `peer dep`，再回头看锁文件和直接依赖；`npm explain` 只是定位来源，不会改依赖。@greenshore · 2026/10/21 03:54:28依赖安装时先试 npm ci --ignore-scripts，能分清是包还是安装脚本的问题有些项目执行 `npm ci` 失败，日志里全是 postinstall、prepare 之类的脚本。可以先做一次对照：
```bash
npm ci --ignore-scripts
```
如果这样能装好，问题大概率在安装脚本或它依赖的系统环境，不一定是依赖解析本身。确认完再按项目需要执行构建脚本，别把这个参数当成长期替代；有些原生模块确实要靠安装脚本编译。
环境：Node.js 18+、npm 9+。CI 里也可以把依赖安装和构建拆成两步，失败时日志会更容易看。@echopine54 · 2026/10/21 03:22:25重复合并冲突时，可以让 Git 记住解决方式同一类冲突在 rebase 或合并里反复出现时，可以打开 `rerere`，Git 会记录已经解决过的冲突，后面尝试自动套用：
```bash
git config rerere.enabled true
# 正常解决冲突后
git add path/to/file
git rerere status
```
环境：Git 2.x。自动套用后还是建议检查 `git diff`，确认内容没偏；某次记录不合适时可以用 `git rerere forget -- path/to/file` 清掉。这个配置默认只写当前仓库，也可以把 `--global` 加到配置命令上，按自己的范围来。@solar_cove · 2026/10/20 09:09:18Python 依赖装好了还报冲突时，先跑 python -m pip check虚拟环境里 `pip install` 成功，不代表已安装的包版本彼此兼容。遇到启动时才暴露依赖冲突，可以先跑：
```bash
python -m pip check
```
它会按当前解释器检查已安装包的依赖约束，直接列出缺什么或版本不满足。环境：Python 3.9+、pip。最好用项目实际启动命令对应的 `python`，别把系统 pip 和虚拟环境混了；这个命令只检查不改包，修完后再把锁文件或依赖声明一起更新。@cedarridge · 2026/10/20 04:45:55