发布脚本核心是自动化“构建→校验→发布”流程，只确保产出物正确、排除干扰文件、执行合规动作，不涉业务逻辑或替代测试；应善用prepublishOnly等npm钩子，避免手动命令与硬编码陷阱。
编写符合规范的发布脚本，核心是把“构建 → 校验 → 发布”三个环节串成可复现、防误操作的自动化流程，而不是手动执行一堆命令。
明确发布脚本的职责边界
发布脚本不负责写业务逻辑，也不替代测试或代码审查。它只做三件事：确保产出物正确、排除干扰文件、执行合规发布动作。npm 会自动触发 prepublishOnly 和 prepare 等生命周期钩子，善用它们比写一个巨长的 publish 脚本更安全可靠。
推荐的 scripts 配置结构
在 package.json 的 scripts 字段中，按职责分层定义：
-
构建类：如
"build": "rollup -c"或"build": "tsc --build"，专注生成dist/目录 -
校验类：如
"check:pkg": "npm pack --dry-run | tar -tz | grep -E '^(dist/|package.json|README.md)$'"，快速确认压缩包内容 -
预发布钩子：用
"prepublishOnly": "npm run build && npm test"，确保每次npm publish前必构建且测试通过 -
发布主脚本（可选）：如
"release": "npm version patch && npm publish"，把版本递增和发布绑定，避免手抖输错版本
必须避开的常见陷阱
很多脚本看似能跑通，但一发布就出问题，往往因为：
立即学习“Java免费学习笔记（深入）”；
- 没设
prepublishOnly，直接npm publish会上传未构建的src/，导致用户require失败 - 用
npm run build && npm publish替代prepublishOnly，一旦构建失败，publish 仍会执行（&&在某些 shell 下不可靠） - 在
scripts里硬编码 registry 地址，比如"publish": "npm publish --registry https://..."，导致团队成员误发到私有源 - 忽略
files字段或.npmignore，把node_modules、tests/、.git全打进去，压缩包体积暴涨甚至发布失败
一个轻量但完整的示例
适用于大多数工具类包（TypeScript + Rollup）：
```json{"scripts": {
"build": "rollup -c",
"test": "vitest",
"preview": "npm pack --dry-run",
"prepublishOnly": "npm run build && npm test",
"release": "npm version patch && git push && git push --tags && npm publish"
},
"files": ["dist", "README.md", "LICENSE"],
"main": "dist/index.js",
"types": "dist/index.d.ts"
}```
