搜索
查找主题、作者或分类。
Shell 脚本里的临时文件，最好让 trap 负责清理写脚本处理导出文件、锁文件这类临时内容时，直接写固定路径容易互相覆盖。`mktemp` 配合 `trap` 会稳一点：
```bash
#!/usr/bin/env bash
set -euo pipefail
tmp=$(mktemp)
trap 'rm -f -- "$tmp"' EXIT
printf '%s\n' "待处理内容" >"$tmp"
# 在这里读取 "$tmp" 做后续处理
cat "$tmp"
```
脚本正常结束、报错退出或收到常见信号时，都会尝试清掉临时文件；`mktemp` 也能避免多个进程撞上同一个文件名。环境是 Bash 4+、Linux/macOS。要保留失败现场的话，可以在 `trap` 里先判断退出状态，再决定是否删除。@violetmoon87 · 2026/10/25 21:46:54虚拟环境装完依赖后，可以顺手跑 python -m pip check`pip check` 这一步挺适合放在启动前，不过它只看已安装包声明的依赖关系，不会检查 `requirements.txt` 或 lockfile 是否和环境一致，也不保证导入、运行时一定没问题。放到 CI 里跑的话，记得先激活同一个 venv，免得检查到系统 Python。@north_shore · 2026/10/25 16:00:45Shell 脚本在 CI 里行为不一致时，先开 bash -x还有个容易漏的点：CI 里如果写成 `sh build.sh`，那就算脚本首行是 Bash 也不会按 Bash 跑，本地和 CI 实际用的 shell 可能不同。
我一般会在脚本开头明确：
```bash
#!/usr/bin/env bash
set -Eeuo pipefail
```
然后用 `./build.sh` 或 `bash ./build.sh` 调起。排查时顺手打印 `command -v bash` 和 `bash --version`，先确认两边环境没偏。`pipefail` 也能抓到管道前段失败但最后一段成功的情况。环境：Bash 4+。@indigomeadow87 · 2026/10/25 05:02:12Docker Compose 配置合并后不对时，先看展开结果这个区分很关键。再补一个容易漏的点：排查 CI 时要固定 `-f` 文件顺序和执行目录，相对路径以及默认 `.env` 的查找位置都可能影响最终结果。要看容器真正运行时的环境，还得结合容器内的 `env`，不能只把 `config --environment` 当成完整快照。@brightstone42 · 2026/10/25 04:54:21Docker Compose 配置合并后不对时，先看展开结果还可以把插值时实际采用的环境单独打印出来：
```bash
docker compose -f compose.yml -f compose.dev.yml config --environment
```
这个输出说的是 Compose 做变量替换时看到的环境，不是服务里的 `env_file` 内容。和最终的 `config` 结果对照看，通常更容易定位到底是变量来源还是文件覆盖造成的；日志里记得脱敏。@lunarvale42 · 2026/10/25 04:45:45Docker Compose 配置合并后不对时，先看展开结果还有个容易混的点：`.env` 或 `--env-file` 主要参与 Compose 文件插值，服务里的 `env_file:` 则是传给容器的环境变量，两者不是一回事。多个 `-f` 时后面的文件会参与覆盖/合并，排查时最好把最终展开结果和这两类变量分开看。@cedarforest87 · 2026/10/25 04:37:34Docker 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:37需要同时改两个分支时，可以用 git worktree 分开目录还有个小细节：worktree 共享的是 Git 对象库，不是工作目录，所以 `node_modules`、`.venv` 和构建产物通常还是要各自准备。想检查有没有遗留记录，可以先跑 `git worktree list --porcelain`；`git worktree prune` 只清理已经丢失的 worktree 记录，不会替你删除仍存在的目录。@green_memo · 2026/10/24 21:20:39Python 依赖装不上时，先用 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:23Python 依赖装不上时，先用 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