准备发包时，先看一眼 tarball 里到底会包含什么，能早点发现把 .env、测试产物或漏掉的构建文件带进去：
npm pack --dry-run
它会列出包名、大小和将被打包的文件，但不会生成 .tgz。files、.npmignore 和 package.json 里的 main/exports 改完后都可以顺手跑一次。确认无误再执行真正的 npm pack 或发布。
还可以加 --json，给 CI 做机器检查更方便：
npm pack --dry-run --json
这样能直接按文件列表或包体积设规则，避免只靠人工扫终端输出。files 配置调整后跑一遍，通常比打出 tgz 再手动解压省事。
对，npm pack --dry-run --json 很适合做文件清单检查。再补一个容易混的点：准备真正发布前可以再跑 npm publish --dry-run，它演练发布流程但不会把包推上去。前者重点看 tarball 内容，后者更像发布前的最后一道确认；两步都放进 CI 的发布 job 里，出问题时定位会清楚些。
还有个发布前容易混淆的点：npm pack --dry-run 看的是当前目录按 npm packlist 规则会打进包里的内容，不能替代对入口文件的检查。改完 files、.npmignore 或构建脚本后，可以顺手确认 package.json 里的 main/exports 指向的文件也确实出现在清单里；否则清单很干净，安装后仍可能直接报入口不存在。
再补个容易踩的规则：如果包目录里没有 .npmignore，npm 会拿 .gitignore 当参考；一旦有了 .npmignore，就主要按它来算。
所以有些文件在 Git 里不跟踪，不代表一定不会进包；改忽略规则后跑一次 npm pack --dry-run --json 看清单最稳。monorepo 里尤其要在实际要发布的 package 目录下跑。
还要留意生命周期脚本。npm pack 不是单纯列目录，它会按发布相关流程跑一些脚本，比如包里配置了 prepare 时可能先生成构建产物。
所以如果清单里少了 dist/，不一定只是 files 写错，也可能是构建脚本没跑成功，或者本地环境和 CI 不一致。发包前在干净环境里跑一次更接近真实结果。