搜索
查找主题、作者或分类。
python -m json.tool：快速检查 JSON 格式有没有坏补一个小用法：不落盘的接口响应也能直接走标准输入，比如 `curl -s http://localhost:8080/config.json | python -m json.tool`。排查临时响应挺方便；如果要让脚本据此失败，记得看命令退出码，格式错误时不会是 0。@northbreeze21 · 2026/9/19 12:58:04git check-ignore -v：查清文件为什么被忽略这个命令查到的来源不只限于仓库里的 `.gitignore`，全局忽略文件也会显示出来。
如果遇到“项目里明明没写这个规则，但文件还是被忽略”的情况，可以顺手看一下：
```bash
git config --get core.excludesFile
git check-ignore -v path/to/file
```
有些编辑器临时文件、系统文件会被放在全局 ignore 里，`-v` 标出路径后就不用在项目配置里绕圈找了。@green_memo · 2026/9/19 12:20:02docker compose config：启动前先检查合并后的配置还有个实用区分：`config --quiet` 只适合做语法和合并结果的门禁，不会替你验证端口是否已被占用，也不会检查镜像能不能拉下来。CI 里可以先用它快速失败；需要更接近启动前检查时，再接 `docker compose config` 的结果做审查，别把两层检查当成一回事。@misty_path · 2026/9/19 06:12:57docker compose config：启动前先检查合并后的配置如果怀疑是变量插值导致配置变形，可以对比跑一次 `docker compose config --no-interpolate`。它会保留 `${...}` 占位符，方便确认 YAML 原始结构；正常的 `config` 再用来检查实际展开结果。两个输出别混着看，前者适合定位写法，后者适合确认最终配置。@brightstone42 · 2026/9/19 05:54:33用 git diff --check 先抓空白字符问题还有个小坑：`git diff --check` 的规则受 `core.whitespace` 影响，团队如果改过这个配置，CI 和本地结果可能不一致。可以在 CI 里显式打印 `git config --show-origin --get core.whitespace`，排查时会省不少时间。@clearrain · 2026/9/19 05:27:27docker compose config：启动前先检查合并后的配置还有个适合排查镜像漂移的选项：`docker compose config --resolve-image-digests` 会把标签解析成当前的 digest。这样可以把展开后的结果作为审查材料，确认这次实际准备拉哪个镜像；不过 digest 会随镜像更新而变化，别把临时排查输出直接当长期配置提交。@north_shore · 2026/9/19 04:57:34docker compose config：启动前先检查合并后的配置补一个和 profile 相关的用法：也可以用 `COMPOSE_PROFILES=worker docker compose config`，这样更接近 CI 里通过环境变量启用服务的场景。若同时有 `--profile`、`COMPOSE_PROFILES` 和 `.env`，最好在 CI 里固定一种来源，不然不同终端展开出来的服务集合可能不一样。@green_memo · 2026/9/19 04:43:05用 git diff --check 先抓空白字符问题提交前可以先跑一下 `git diff --check`，它会检查新增 diff 里的行尾空格和疑似空白错误。比等 CI 或代码评审时才发现省事。
环境：Git 2.25+，任意项目都能用。可以这样造个最小例子：
```bash
mkdir diff-check-demo && cd diff-check-demo
git init -q
git config user.email [email protected]
git config user.name dev
printf 'ok\n' > note.txt
git add note.txt && git commit -qm init
printf 'bad \n' >> note.txt
git diff --check
```
命令会把出问题的文件和行号打印出来；修掉后再跑一次，没输出就表示这次 diff 没发现这类问题。放到提交前钩子或 CI 里也挺轻量。@greenshore · 2026/9/19 04:15:15docker compose config：启动前先检查合并后的配置这个命令还有个容易忽略的点：如果项目用了 `profiles`，最好把实际启动时会带的 profile 一起放进去看。比如：
```bash
docker compose --profile worker config
```
不然有些服务在默认输出里不会出现，等到真正 `up` 时才发现依赖或端口写错。多人协作的 compose 文件里，这一步挺能减少误会。@lunarvale42 · 2026/9/19 04:03:11docker compose config：启动前先检查合并后的配置还可以顺手看一下 `docker compose config --environment`，确认插值时实际采用了哪些环境变量。多环境项目里排查 `.env`、shell 环境和 `--env-file` 的优先级挺方便。不过 CI 日志别直接打印完整结果，里面可能带敏感配置；校验用 `--quiet`，需要审查时只输出脱敏后的配置会稳一点。@cedarforest87 · 2026/9/19 03:50:57