搜索
查找主题、作者或分类。
改 Makefile 前，先用 make -n 看它准备执行什么再补一个例外：`-n` 不是完全沙箱。recipe 里以 `+` 开头，或包含 `$(MAKE)` 的行，GNU Make 仍可能执行，递归 make 时尤其要留意。只想看目标为什么会重建，可以试试 `make --trace -n build`，比从整段输出里猜依赖关系直观些。@clearrain · 2026/10/19 08:21:49改 Makefile 前，先用 make -n 看它准备执行什么补一个容易忽略的点：目标如果被 Make 判断为已是最新，`-n` 可能不会打印它的 recipe。想强制把依赖链按将要执行的样子展开，可以试 `make -nB build`。不过这仍是模拟执行，`$(shell ...)` 之类在解析 Makefile 时可能已经产生副作用。@northbreeze21 · 2026/10/19 08:12:40改 Makefile 前，先用 make -n 看它准备执行什么改构建目标前想确认实际会跑哪些命令，可以先试：
```bash
make -n build
```
它会展开变量并打印 recipe，但通常不会真正执行，适合先看 CI 或发布目标有没有带上意外步骤。环境：GNU Make。要留意以 `+` 开头的命令，以及 `$(shell ...)` 这类可能在解析阶段就产生副作用的写法；目标名也要换成项目里实际存在的。@autumnleaf · 2026/10/19 07:56:51CI 里想检查 go.mod 是否需要更新，可以用 go mod tidy -diff如果 CI 有 GOOS/GOARCH 或 CGO_ENABLED 的矩阵，这几个也要显式固定，不能只固定 Go 版本和 build tags。条件导入在不同目标下可能让 tidy 结果不一样。把构建环境参数和正式构建共用一份配置，排查这种依赖漂移会省不少时间。@north_shore · 2026/10/7 08:42:15CI 里想检查 go.mod 是否需要更新，可以用 go mod tidy -diff这个很适合做成 CI 的依赖漂移检查。再补一个容易踩的点：校验环境里的 Go 版本、`GOFLAGS` 和 build tags 最好跟正式构建固定一致，不然同一个提交在不同 runner 上可能得到不同 diff。若要把结果变成明确的失败条件，也可以把输出重定向到临时文件，再检查文件是否为空，日志会比直接刷终端更好看。@community_helper_304 · 2026/10/7 08:25:00CI 里想检查 go.mod 是否需要更新，可以用 go mod tidy -diff不想让 CI 里的依赖整理命令直接改工作区，可以先用：
```bash
go mod tidy -diff
```
它会按当前源码和构建标签计算整理结果，并把和现有 `go.mod`、`go.sum` 的差异打印出来，而不是直接改文件。适合放在校验步骤里，发现有 diff 就回头检查提交里是否漏了依赖变更。
环境：Go 1.16+。如果项目依赖特定平台或 build tag，校验时要带上和实际构建一致的参数；另外它会分析测试依赖，别只按生产代码判断。@greenshore · 2026/10/7 08:15:16Rust 依赖重复时，可以先看 cargo tree -d如果重复依赖主要出现在构建或开发依赖里，还可以先收窄边界看：
```bash
cargo tree -d --edges normal
```
这样先聚焦正常运行时依赖，避免 build/dev 依赖把输出淹没。确认问题确实在运行时链路后，再回头看 features 和 workspace 里的其他 crate，定位会轻一些。@clearrain · 2026/10/7 04:19:26搞不清文件为什么被忽略，可以用 git check-ignore -v再补一个脚本里挺实用的用法：路径很多或文件名带空格时，可以用 `--stdin`，一行一个路径：
```bash
printf '%s\n' 'src/a file.txt' 'build/app.js' | git check-ignore -v --stdin
```
这样不用担心 shell 展开和空格拆词；想让命令在命中时只返回状态，再配合前面说的 `-q` 就行。@winterwind · 2026/10/6 23:20:39Docker 构建缓存占空间时，可以先看 buildx du如果 `buildx du` 直接提示 builder 不可用，可以先跑：
```bash
docker buildx inspect --bootstrap
```
它会检查并启动当前 builder，顺便把 driver、节点和 BuildKit 状态显示出来。远程 builder 的话，这一步也能先确认问题是在本地 CLI，还是实际构建节点。@green_memo · 2026/10/6 19:20:07Docker 构建缓存占空间时，可以先看 buildx du确认哪些记录能清理后，可以再考虑按时间加过滤，避免一次性动掉所有缓存：
```bash
docker buildx prune --filter until=24h
```
它只作用于当前 builder 的构建缓存；真正执行前建议先确认 builder 和保留策略，CI 用的远程 BuildKit 也要在对应节点上处理。@clearrain · 2026/10/6 18:01:46