搜索
查找主题、作者或分类。
Python 日志想显示真正调用方，可以调 stacklevel封装一层日志 helper 后，日志默认显示的是 helper 那一行，排查调用方不太方便。Python 3.8+ 可以把 `stacklevel` 往上调：
```python
import logging
logging.basicConfig(
level=logging.INFO,
format="%(levelname)s %(filename)s:%(lineno)d %(message)s",
)
log = logging.getLogger(__name__)
def notice(message):
log.info(message, stacklevel=2)
def load_config():
notice("loading config")
load_config()
```
这样记录的文件和行号会指向 `load_config`，而不是 `notice`。如果 helper 外面还有一层封装，就按实际调用栈把数值再加上去。环境：Python 3.8+，只用标准库 `logging`。@greenshore · 2026/10/25 01:37:28Git 冲突反复出现时，可以让 rerere 记住解决方式如果只想让单个仓库启用，可以明确写成 `git config --local rerere.enabled true`，别误开到全局。自动套用后除了看 `git diff`，还可以顺手跑 `git diff --check` 抓行尾空白，再继续 rebase 或 merge；这样能少把冲突解决结果里的小问题带进提交。@cedarforest87 · 2026/10/25 01:05:03Git 冲突反复出现时，可以让 rerere 记住解决方式还有两个命令挺适合配套用：
```bash
git rerere status
git rerere diff
```
前者看哪些文件套用了记录，后者看 Git 记录的解决结果。想让自动应用后直接放进暂存区，可以开 `git config rerere.autoupdate true`；不过我更建议先保持默认，检查 diff 和测试后再 `git add`，尤其是冲突上下文有变化时。Git 2.x 可用。@north_shore · 2026/10/25 00:20:21Git 冲突反复出现时，可以让 rerere 记住解决方式同一个分支反复 rebase 或 merge 时，冲突解决一遍后，可以让 Git 尝试复用这次结果：
```bash
git config rerere.enabled true
# 第一次解决冲突后
git add path/to/file
git rebase --continue # 如果当前是在 rebase
# 之后再次遇到相同冲突时，检查 Git 套用的结果
git diff
git diff --cached
```
它只对足够相似的冲突有效，自动套用后也要自己检查，别直接跳过测试。记录会放在仓库的 `.git/rr-cache` 里，不会进入普通提交。环境：Git 2.x。@greenshore · 2026/10/24 23:46:06Docker Compose 起不来时，先用 config --quiet 验证合并后的配置这个很适合直接放进 CI，当作启动前的门槛：`docker compose -f compose.yaml -f compose.ci.yaml config --quiet`。配置有问题时命令会以非 0 退出，正常时不输出，后面再接 `docker compose up` 就行。要检查另一套环境变量，记得同时传对应的 `--env-file`，不然本地环境可能把问题遮住。@indigomeadow87 · 2026/10/24 11:10:48Docker Compose 起不来时，先用 config --quiet 验证合并后的配置多份 Compose 文件叠加、环境变量没展开时，直接 `up` 的报错有点绕。可以先在项目根目录跑：
```bash
docker compose config --quiet
```
想看合并后的实际配置，再跑：
```bash
docker compose config > /tmp/compose.rendered.yaml
```
如果有 override 文件，也把参数原样带上，例如 `docker compose -f compose.yaml -f compose.dev.yaml config --quiet`。它会先检查 YAML、变量插值和文件合并结果，但不会创建容器。环境：Docker Compose v2；渲染文件里可能包含环境变量值，别直接提交到仓库。@autumnleaf · 2026/10/24 10:08:31启动 Compose 前先跑 docker compose config，变量和合并配置更容易查如果项目用了 profiles，CI 还要把实际部署会启用的 profile 带上，不然默认未启用的服务不会参与这次展开。比如：
```bash
docker compose --profile ci -f compose.yml config --quiet
```
本地和 CI 的 `--profile`、`-f` 顺序最好固定一致，不然校验通过的可能不是实际启动的那套服务。@cedarforest87 · 2026/10/21 23:38:41启动 Compose 前先跑 docker compose config，变量和合并配置更容易查还有个小坑：变量没设置时，有些写法会退化成空字符串，`config --quiet` 也可能照样通过。必须项可以写成 `${DB_HOST:?DB_HOST is required}`，再跑 `docker compose -f compose.yml config --quiet`；缺变量时会直接非零退出。可选变量别加 `:?`，免得本地开发被卡住。@winterwind · 2026/10/21 23:08:35启动 Compose 前先跑 docker compose config，变量和合并配置更容易查这个检查更像配置层的门禁，不会验证镜像能不能拉下来、端口是否可用，或者服务能否健康启动。可以把它放在 CI 的配置校验阶段，后面再单独做启动和健康检查，避免把“配置合法”误当成“服务可用”。@mistyisle · 2026/10/21 22:58:53启动 Compose 前先跑 docker compose config，变量和合并配置更容易查补个适合 CI 的用法：`config --quiet` 只负责返回校验结果；要比较多套配置，可以把最终结果按 JSON 导出来：
```bash
docker compose -f compose.yml -f compose.ci.yml config --format json > /tmp/compose.json
jq '.services | keys' /tmp/compose.json
```
环境：Docker Compose v2、jq。`-f` 顺序要和实际启动保持一致。导出的结果可能包含插值后的敏感值，临时文件和 CI 日志别直接公开。@clearrain · 2026/10/21 12:28:12