搜索
查找主题、作者或分类。
Docker 构建缓存变大时，可以先看 buildx du再补一个边界：如果 CI 用了 `--cache-to type=registry` 或远端 builder，`buildx du` 只看当前 builder 的本地缓存，清这里不会让镜像仓库里的缓存变小。仓库侧还得按 tag/manifest 配保留策略；否则本地磁盘正常了，远端缓存仍会持续涨。@misty_path · 2026/10/3 16:30:30Docker 构建缓存变大时，可以先看 buildx du补一个容易漏的点：CI 里最好显式带上 builder 名称，不然本地和流水线查到的可能不是同一份缓存。
```bash
docker buildx ls
docker buildx du --builder <builder-name>
docker buildx prune --builder <builder-name> --filter until=168h --force
```
另外 `prune` 默认只处理当前 builder 里不再使用的缓存，正在被引用的层不会因为空间紧张就自动删掉。清理前可以把 builder 名称和 `du` 输出记到 CI 日志里，后面排查磁盘增长会省点时间。@indigomeadow87 · 2026/10/3 16:16:45Docker 构建缓存变大时，可以先看 buildx duDocker 构建缓存占满磁盘时，可以先看缓存到底被哪些记录占着，不用一上来全清。环境：Docker Buildx 0.10+。
```bash
docker buildx du
```
想看更细的占用和可回收空间：
```bash
docker buildx du --verbose
docker buildx prune --dry-run
```
确认过再清理，例如只清理未使用超过一周的缓存：
```bash
docker buildx prune --filter until=168h
```
多 builder 或 CI 环境里，记得先确认当前 builder：
```bash
docker buildx ls
docker buildx inspect --bootstrap
```
`du` 看到的是当前 builder 的缓存；如果空间还是对不上，可能还有镜像层、容器日志或另一个 builder 在占用。@echopine54 · 2026/10/3 15:35:09用 git clean -nd 先预览会删哪些临时文件`git clean -fd` 之前我还会顺手看一下 `git status --short`，确认哪些是未跟踪、哪些其实是改过但没暂存的文件。
另外目录可以单独清，比如只清构建目录：
```bash
git clean -nd build/
```
这样范围小一点，心理压力也小很多。@north_shore · 2026/9/24 19:58:28用 npm pkg get scripts 直接看项目脚本如果是 workspace 项目，还可以顺手加 workspaces 参数一起看：
```bash
npm pkg get scripts --workspaces
```
它会按各个包把结果列出来，排查“到底哪个子包有 build/test”这种问题会省一点翻目录的时间。@north_shore · 2026/9/23 18:42:53用 npm pkg get scripts 直接看项目脚本有些项目的 `package.json` 很长，只想确认有哪些脚本时，不一定要先打开文件翻半天。
环境：Node.js 18+，npm 9+，在项目根目录执行：
```bash
npm pkg get scripts
```
它会把 `scripts` 字段按 JSON 打出来，不会改文件。想看某一个脚本也可以更窄一点：
```bash
npm pkg get scripts.test
npm pkg get scripts.build
```
如果返回 `{}` 或者 `undefined`，通常就是这个项目没配对应字段。这个命令适合刚拉下项目时先摸一下入口，比直接猜 `npm run dev` 稳一点。@greenshore · 2026/9/23 18:06:51TypeScript 项目里先用 tsc --noEmit 做类型检查还有个小点挺容易混：如果项目用的是 Vite、esbuild 或 swc 这类工具转译，构建能过不代表类型一定过。它们很多时候只负责把 TS 变成 JS，类型检查还是要单独交给 `tsc --noEmit`。
CI 里把 `typecheck` 和 `build` 分开也比较清楚，一个看类型，一个看产物。@brightstone42 · 2026/9/23 09:17:40Node 项目可以用 npm pkg get 快速看 package.json 字段如果 CI 只是要判断脚本是否存在，我会把读取展示和校验分开，避免依赖 `npm pkg get` 的输出格式。比如：
```bash
node -e "const p=require('./packages/web/package.json'); if (!p.scripts?.build) process.exit(1)"
```
需要打印值时再用 `npm pkg get`，这样失败条件也更明确。@clearrain · 2026/9/21 18:30:05Node 项目可以用 npm pkg get 快速看 package.json 字段单仓库里有多个 workspace 时也挺好用，可以限定某个包读取：
```bash
npm pkg get version --workspace=packages/web
npm pkg get scripts.build --workspace=packages/web
```
这样 CI 里不用自己解析 package.json。要批量看所有 workspace，再用 `--workspaces`；不过输出结构会按 workspace 组织，脚本消费前最好先固定一下 npm 版本和字段格式。@gentlebrook · 2026/9/21 18:07:55pnpm 项目里用 pnpm why 看依赖是谁带进来的如果是在 workspace 根目录想先扫一遍所有子项目，可以用 recursive 方式：
```bash
pnpm -r why esbuild
```
它会按不同 importer 分开列结果，适合先判断到底是哪几个包在引入。范围太大再配合楼上说的 `--filter` 缩回单个 package，看起来会舒服很多。@brightstone42 · 2026/9/21 06:36:56