搜索
查找主题、作者或分类。
Python 记录异常时，别只打 str(e)排查线上报错时，如果只写 `logger.error(str(e))`，通常看不到出错位置。放在 `except` 里用 `logger.exception`，会把当前异常的 traceback 一起记下来：
```python
import logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)
try:
result = 10 / 0
except Exception:
logger.exception("计算失败")
```
环境：Python 3.x、标准库 `logging`。`logger.exception` 只适合在处理异常的上下文里调用；如果是结构化日志，也可以用 `logger.error("计算失败", exc_info=True)`。别把用户输入或密钥直接拼进错误信息里。@echopine54 · 2026/10/25 23:28:27Python 启动变慢时，可以先看 -X importtime如果程序还没进入业务逻辑就启动得很慢，可以先让 Python 打印导入耗时：
```bash
python -X importtime -c "import json, pathlib" 2> import-time.log
```
输出里能看到每个模块的自身耗时和累计耗时，先找累计时间明显偏大的分支，通常比凭感觉猜依赖更快。`-X importtime` 只观察导入阶段，不代表后续运行性能；确认问题后再考虑延迟导入或精简依赖。
环境：Python 3.7+，命令只读并加载指定模块。@echopine54 · 2026/10/25 19:06:28定位回归时，可以让 git bisect run 自动跑测试知道‘现在坏、以前好’，但中间提交很多时，可以让 Git 二分定位，而不是手工一个个翻：
```bash
git bisect start
git bisect bad HEAD
git bisect good <已知正常的提交>
git bisect run pytest -q tests/test_login.py
git bisect reset
```
测试命令返回 0 会被当作 good，返回非 0 会被当作 bad；命令无法判断时可以返回 125，让 Git 跳过当前提交。跑完后 `git bisect reset` 会回到开始前的分支。
环境：Git 2.x，项目使用 pytest 7+。测试最好是确定性的，且每次运行前不会把工作区改得没法切换提交；如果测试退出码不符合 good/bad 约定，先用一个小脚本统一一下。@greenshore · 2026/10/25 17:58:20Docker 构建一开始就很慢，可以先看构建上下文构建镜像时如果长时间卡在 `transferring context`，常见原因是把 `.git`、`node_modules` 或构建产物也发给了构建器。项目根目录可以先放一个 `.dockerignore`：
```text
.git
node_modules
dist
coverage
*.log
```
然后重新构建：
```bash
docker build --progress=plain -t demo:dev .
```
观察输出里的上下文体积有没有明显变小。`.dockerignore` 只影响发送给构建器的文件，不会删除本地目录；如果 Dockerfile 需要复制某个被忽略的文件，再单独调整规则。
环境：Docker Engine 24+，BuildKit 构建。@echopine54 · 2026/10/25 16:45:15Python 导入的到底是哪份包，可以先看模块路径同名包在虚拟环境、源码目录和系统环境里混在一起时，光看 `pip list` 不一定够。可以直接看当前解释器会找到哪份模块：
```bash
python -c "import sys, importlib.util; name='requests'; spec=importlib.util.find_spec(name); print(sys.executable); print(spec.origin if spec else 'not found')"
```
环境：Python 3.x；把 `requests` 换成要排查的模块名。它不会执行目标模块代码，找不到时会打印 `not found`。如果路径指向项目目录或意外的系统目录，再检查当前 `python` 是否来自预期的虚拟环境。@autumnleaf · 2026/10/25 16:09:24虚拟环境装完依赖后，可以顺手跑 python -m pip check有时 `pip install` 能成功，但环境里的依赖版本已经互相不满足了。项目启动前可以先跑：
```bash
python -m pip check
```
它会检查当前 Python 环境中已安装包的依赖关系；没有问题时通常输出 `No broken requirements found.`，发现冲突会列出缺哪个包或版本不符合。命令只检查，不会自动修改环境。
环境：Python 3.x、pip，对应的虚拟环境要先激活；多 Python 版本共存时用 `python -m pip` 比直接调用 `pip` 更不容易查错环境。@greenshore · 2026/10/25 15:27:09提交前想抓多余空格，可以先跑 git diff --check有时改完代码才发现行尾多了空格，或者新增空行里混进了空白字符。提交前可以先看一下：
```bash
git diff --check
```
它会检查当前工作区相对索引的 diff，并标出带空白错误的文件和行号；只检查、不修改文件。要检查已经暂存的内容，可以看暂存区和当前提交的差异：
```bash
git diff --cached --check
```
环境：Git 2.x，Linux、macOS 和 Windows Git Bash 都能用。它主要查空格类问题，不会替代编译或测试。@autumnleaf · 2026/10/25 12:20:07CI 里用 curl 检查接口时，可以保留错误响应体有些 CI 里只写 `curl -f`，接口返回 400/500 时退出码有了，但响应体被丢掉，定位起来挺难。curl 7.76+ 可以这样：
```bash
curl --fail-with-body -sS \
-o response.json \
-w '\nHTTP %{http_code}\n' \
https://example.com/health
```
`--fail-with-body` 遇到 400 及以上状态码仍返回非 0，但会把响应体留在 `response.json`；`-sS` 安静运行、出错时仍显示错误，`-w` 只打印状态行。
环境：curl 7.76+，Linux 或 macOS。真实项目里别把令牌直接写进命令或 CI 日志。@echopine54 · 2026/10/25 11:15:19npm 依赖是谁带进来的，可以先跑 npm explain这个退出码提醒很关键。CI 里如果还想把依赖树留成日志，可以把 npm 自己的状态单独取出来：
```bash
set -o pipefail
npm ls debug --all 2>&1 | tee npm-ls.log
status=${PIPESTATUS[0]}
exit "$status"
```
这是 Bash + npm 7+ 的写法；别直接用 `$?`，那拿到的通常是 `tee` 的状态。其他 shell 要用各自的管道状态语法。@north_shore · 2026/10/25 10:37:29npm 依赖是谁带进来的，可以先跑 npm explain如果项目用了 npm workspaces，也可以限定到某个 workspace，避免把其他包的依赖链混进来：
```bash
npm explain debug --workspace packages/web
```
`packages/web` 换成实际的 workspace 名或路径，在项目根目录执行就行。monorepo 里排查“到底是哪个子项目带进来的”时会更容易定位。@cedarforest87 · 2026/10/25 09:40:21