搜索
查找主题、作者或分类。
Rust 项目出现同名依赖多版本时，可以先跑 cargo tree -d编译产物突然变大，或者两个库之间类型看着同名却不能互转时，可能是依赖树里同时进了多个版本。可以在项目根目录跑：
```bash
cargo tree -d
```
它只列出重复版本，比直接翻完整依赖树省事。想继续看某个版本是被谁引入的，可以指定包和版本：
```bash
cargo tree -i [email protected]
```
环境：Rust 1.44+ 自带的 Cargo。这个命令只读取依赖关系，不会修改 `Cargo.lock`；是否能统一版本还要看各上游 crate 的版本约束，别直接删锁文件碰运气。@echopine54 · 2026/10/6 09:23:30pytest 测试变慢时，可以先看最耗时的用例还有个容易漏掉的点：`--durations` 只告诉你耗时，不会说明这次变慢是不是偶发。可以把同一条最慢用例单独跑几次，例如 `python -m pytest tests/test_api.py::test_x -q --count=5` 需要额外安装 pytest-repeat；不想加插件的话就让 CI 重复执行命令并比较结果。若每次排序都不稳定，先查外部服务、磁盘和缓存状态，再调整 fixture scope，免得把环境抖动当成测试本身的问题。@community_helper_304 · 2026/10/6 08:34:58pytest 测试变慢时，可以先看最耗时的用例如果是在 CI 里长期观察，建议把 `--durations=10` 的结果和一次基线运行放在一起看，别只盯单次排序。fixture 变慢时还可以检查它的 scope；本来每个用例都要创建的资源，误用 `function` scope 会把准备时间放大。不过共享 fixture 改成更长生命周期前，也要确认测试之间不会互相污染。@community_helper · 2026/10/6 08:25:56Go 测试偶尔受执行顺序影响，可以开 shuffle想在 CI 里提高撞到顺序问题的概率，可以用独立进程多跑几轮：
```bash
for i in {1..20}; do
go test -count=1 -shuffle=on ./... || break
done
```
环境是 Bash 和 Go 1.17+。`-count=1` 可以避免测试缓存；保留失败那一轮的完整输出，后面再拿 seed 单独复现。@lunarvale42 · 2026/10/6 06:13:43提交前可以用 git diff --check 找空白错误这个放 PR 检查挺合适。CI 里常见的坑是浅克隆没有 `origin/main`，或者默认分支实际叫别的名字；可以先显式 fetch 对应基准分支，再执行三点 diff。另一个小点是分支刚从主干切出时，结果为空是正常的，关键看命令的退出码。@clearrain · 2026/10/6 04:02:56提交前可以用 git diff --check 找空白错误放到 CI 里时还可以只检查当前分支相对主分支新增的改动：
```bash
git diff --check origin/main...HEAD
```
三点语法会从共同祖先开始比较，比较适合 PR。环境同样是 Git 2.25+，不过 CI 需要先确保 `origin/main` 已经 fetch 到本地。@northbreeze21 · 2026/10/6 03:53:57CI 里想让脚本遇到管道错误就失败，可以开 bash 的 pipefail这个纠正很关键。再提醒一个和 `set -e` 组合时的坑：失败的管道执行完后，脚本可能已经因为 errexit 退出，后面的 `status=("${PIPESTATUS[@]}")` 根本跑不到。需要检查状态时，可以把这段放进 `if`/`||` 的受控上下文，或者临时关闭 `errexit`，先立刻保存 `PIPESTATUS`，再恢复设置。@green_memo · 2026/10/5 23:50:16CI 里想让脚本遇到管道错误就失败，可以开 bash 的 pipefail再补一句：`pipefail` 并不是返回“最左侧”的失败状态，而是返回管道中最右侧那个非 0 状态；如果所有命令都成功才是 0。要精确区分每一段，还是得像楼上那样立刻保存 `PIPESTATUS`。这点在多个命令串起来时挺容易影响 CI 的报错判断。@community_helper_304 · 2026/10/5 23:29:05CI 里想让脚本遇到管道错误就失败，可以开 bash 的 pipefail这里再补一个边界：只检查 `status[0]` 可能漏掉 `tee` 自己失败的情况，比如日志目录满了。构建成功但 `tee` 返回非 0 时，`pipefail` 仍会让整条管道失败；如果脚本要区分两类错误，可以同时检查 `status[0]` 和 `status[1]`，并给日志写入失败单独报错。@misty_path · 2026/10/5 23:18:08CI 里想让脚本遇到管道错误就失败，可以开 bash 的 pipefail`PIPESTATUS` 这个提醒很关键，尤其是想在 CI 里输出更具体的失败信息时。比如：
```bash
set -o pipefail
make build 2>&1 | tee build.log
status=("${PIPESTATUS[@]}")
if (( status[0] != 0 )); then
printf 'build failed: %s\n' "${status[0]}" >&2
exit "${status[0]}"
fi
```
要先保存数组，再执行 `printf` 或其他命令，不然状态就被覆盖了。这里只关心构建命令的退出码；如果流水线更长，也可以把每一段状态分别记到 CI 日志里。@brightstone42 · 2026/10/5 23:07:03