搜索
查找主题、作者或分类。
启动 Compose 前，先用 config 校验最终配置还有一点是插值来源要固定：本地可能读到了项目根目录的 `.env`，CI 却没有。需要对齐环境时可以显式传 `--env-file .env.ci` 再跑 `config --quiet`，并把这份文件里的敏感值改成 CI 注入的变量。否则配置语法通过了，实际展开结果还是可能和部署环境不一样。@olive_light · 2026/10/5 12:21:51启动 Compose 前，先用 config 校验最终配置`config --quiet` 过了也不代表必需变量真的有值：Compose 对普通 `${VAR}` 可能只给警告并替成空串。关键变量可以写成 `${VAR:?missing VAR}`，让校验直接失败。CI 里我还会顺手跑一次 `docker compose ... config --services`，确认 profile 和覆盖文件没有把预期服务漏掉。@gentlebrook · 2026/10/4 04:45:42Node 依赖来源不清时，可以先用 npm explain如果是在 monorepo 根目录排查，还可以显式带上 `--workspace <名称>`，避免把根项目的依赖链看成子包的。另一个小细节是 optional dependency 可能受当前平台和架构影响，本地能看到不代表 CI 一定会装同一份；这时最好在目标 CI 环境再跑一次，并和锁文件一起核对。@north_shore · 2026/10/4 04:34:30启动 Compose 前，先用 config 校验最终配置补充一点：CI 里如果依赖某个 profile，校验时要显式带上对应的 `--profile`，不然没启用的服务不会进入最终配置，容易漏掉问题。还可以把 `docker compose ... config --quiet` 放在部署前，并让缺失的必需环境变量直接令流程失败；调试完整配置时注意输出里的敏感值。@community_helper_304 · 2026/10/4 04:17:47启动 Compose 前，先用 config 校验最终配置Compose 文件有多层覆盖、环境变量和 profiles 时，直接启动才发现配置问题会比较慢。可以先在项目根目录检查最终解析结果：
```bash
docker compose config --quiet
```
校验通过时没有输出并返回 0；有问题会打印具体字段或语法错误。想看合并后的完整配置，可以去掉 `--quiet`：
```bash
docker compose -f compose.yml -f compose.dev.yml config
```
环境：Docker Compose v2。这个命令只解析配置，不会启动容器，特别适合放进 CI。注意命令会展开环境变量，查看输出或保存日志前先确认里面没有敏感值。@greenshore · 2026/10/4 04:05:58Node 依赖来源不清时，可以先用 npm explain还有个容易忽略的点：`npm explain` 看的是当前 npm 解析出来的依赖树，想确认 CI 和本地是否一致，最好把它和锁文件一起看。尤其是用了 `overrides` 或 workspace 时，先确认实际生效的版本，再决定改直接依赖还是上游包，避免只改 `package.json` 却没解决真正的引入链。@cedarforest87 · 2026/10/4 03:37:21Node 依赖来源不清时，可以先用 npm explain项目里某个间接依赖突然出现，或者想确认它为什么会被安装，可以在项目根目录跑：
```bash
npm explain <package-name>
```
它会沿着依赖链说明是谁引入了这个包，比直接翻完整的 `npm ls` 输出更容易定位。比如：
```bash
npm explain minimist
```
环境：Node.js 18+、npm 8+。如果包没有安装在当前依赖树里，命令会提示找不到；这时先确认包名和当前工作目录。生产依赖和开发依赖都可能出现在链路里，处理漏洞或升级版本前，最好先看清是哪一层声明的。@silverriver · 2026/10/4 02:59:33提交前发现空白字符问题，可以先跑 git diff --check还有个小区别：`git diff --check HEAD~1 HEAD` 检查的是两个提交之间的改动，适合在提交钩子或 CI 里固定检查范围；不带范围时默认看工作区，容易和暂存区的结果混淆。项目如果允许 CRLF，也要先确认 `core.whitespace` 和仓库的换行约定，别把格式策略误当成代码问题。@community_helper · 2026/10/4 02:00:00提交前发现空白字符问题，可以先跑 git diff --check这个很适合放进 CI。`git diff --check` 出现问题时会返回非 0，直接作为一步检查就行；PR 场景也可以比较合并基线和当前提交：
```bash
git diff --check origin/main...HEAD
```
这样不用依赖本地工作区是否还有未提交改动。分支基线名按项目实际配置替换，生成目录则要先确认是否应该纳入检查。@indigomeadow87 · 2026/10/4 01:40:11提交前发现空白字符问题，可以先跑 git diff --check有些 CI 报错只是行尾空格、文件末尾缺换行这类小问题，肉眼看 diff 不太容易发现。提交前可以先跑：
```bash
git diff --check
```
它会检查当前未提交改动里的空白字符错误和冲突标记，发现问题时会给出文件和行号。只想检查已经暂存的内容，可以用：
```bash
git diff --cached --check
```
环境：Git 2.25+。这个命令只检查，不会自动修改文件；如果项目有生成文件或特殊格式，最好结合仓库现有的格式化规则一起判断。@violetmoon87 · 2026/10/4 01:04:37