4.2 生命周期脚本执行机制

4.2 生命周期脚本执行机制

本节摘要：包管理器在安装的多个节点上执行依赖包声明的脚本：preinstall 先行、install 居中、postinstall 收尾，运行期还有一系列钩子。脚本机制让"安装即配置"成为可能，也让每个包在安装时拿到执行任意代码的权力。本节勘验触发时序与执行环境，给出脚本审计的三步方法，并说明现代工具如何用脚本白名单在便利与安全之间重新划线。

一段可疑的安装日志

先看一段真实感很强的日志，问题藏在细节里：

$ npm install some-helper-lib
added 1 package, and audited 214 packages in 6s

> some-helper-lib@2.1.0 postinstall
> node ./scripts/setup.js

[setup] writing config to home directory...
​

装一个"工具库"，安装日志末尾却出现"往用户主目录写配置"的输出。多数人会忽略这两行——装完了、没报错、能用。但勘验视角会立刻发问：一个纯工具库为什么需要 postinstall 脚本？它往主目录写了什么？这段脚本是谁审计过的？ 这三问就是本节要装备给你的全部工具。

触发时序：钩子挂在哪里

生命周期脚本是一组约定命名的钩子，包管理器在特定节点执行它们。安装相关的核心钩子按时间排列如下：

preinstall   安装动作开始前   项目根的清单里声明才生效
install      包安置完成后     单包声明或项目声明
postinstall  全部安置完成后   最常用 编译 生成 配置都在这
prepack / prepare / prepublish  与发布打包相关的钩子
​

三条执行规则决定脚本的行为边界。其一，顺序确定：同名钩子按依赖拓扑序执行，项目根的 preinstall 先于一切。其二，工作目录是包自身目录：脚本里的相对路径都相对于该包的安装位置，这也是为什么脚本里常用绝对路径或环境变量定位。其三，拿到的是完整 shell 环境：脚本可以访问环境变量、网络与文件系统——能力与普通命令行进程无异，这就是风险的全部来源。

{
  "name": "some-native-tool",
  "scripts": {
    "install": "node-gyp rebuild",
    "postinstall": "node ./scripts/link-bin.js"
  }
}
​

上面这种声明形态是最常见的合法用例：原生模块编译加二进制链接。4.3 节专门勘验这类场景。合法与恶意脚本在机制上毫无区别——区别只在脚本内容做了什么，而这无法从声明本身看出来。

图 4-2 安装期脚本的执行时序与审计点

脚本审计三步法

把勘验视角变成固定流程。引入一个带安装期脚本的包之前，走三步：

# 第一步 看声明：这个包声明了哪些钩子
$ npm view some-helper-lib scripts
# 输出 scripts 清单 —— 纯工具库出现 postinstall 即进入重点观察

# 第二步 看内容：脚本文件在安装前就能审阅
$ npm pack some-helper-lib --dry-run   # 或在 registry 页面查看源码包内容
# 重点读钩子指向的入口文件：是否下载执行外部内容 是否读取敏感环境变量

# 第三步 看行为：在隔离环境里装一次 观察副作用
$ npm install --ignore-scripts some-helper-lib   # 先禁脚本安装
$ npm rebuild some-helper-lib --foreground-scripts
# 前台执行脚本 逐行看它输出什么 动了哪些目录
​

第三步里的 ignore-scripts 参数值得单独记住：它让安装只做"取件落盘"、跳过全部脚本，是安全审查与脚本故障隔离的通用手段。Yarn 侧对应配置化选项，pnpm 则更进一步——默认阻止未列入白名单的包执行脚本。三大工具在脚本管控上的梯度（全放行 → 可选禁止 → 默认白名单），恰好构成一条安全水位线，第六章会把它放进攻防全景。

团队级策略：把脚本的权力关进名单

个人审计三步法之外，团队需要一致的策略配置。两条路线各有取舍：

路线一：默认放行加审计抽查。 开发体验不受影响，靠代码评审与流水线扫描兜底。代价是恶意包的执行窗口先于审计打开——脚本在安装那一刻就已经跑完。

路线二：默认禁止加白名单放行。 只有名单内的包允许执行脚本，新包进入名单需要走一次人工审计。代价是新依赖的接入多一步流程，原生模块较多的项目名单维护成本更高。

我的建议是按项目性质选：业务应用与处理敏感数据的项目走路线二，攻击面值得这点流程成本；内部工具与原型项目走路线一加流水线扫描。无论选哪条，ignore-scripts 的可用性都要定期演练——真出事故需要紧急安装时，它是止血开关。

安装期之外：脚本家族的其他成员

安装期三钩子之外，生命周期脚本还有一族运行期成员：测试前后、发布前后、版本变更前后各有对应钩子。它们与安全话题的关联值得点破：发布类钩子在本地执行，历史上曾有恶意包在这里藏污纳垢——发布动作同样值得在隔离环境进行，凭据管理遵循 6.1 节的同一套原则。

另一处实用细节是 prepare 钩子：从代码仓库直接安装（而非从打包产物安装）时它会触发，用于现场构建——这也是为什么团队不应该把脚本禁用做成"一刀切"，某些从源码安装的包缺了它跑不起来。一句话收束：把脚本家族的完整名单通读一遍，知道有哪些钩子、各自何时触发，是判断"这个包凭什么需要脚本"的前提——审计的起点永远是知情。

本节要点回顾

• 安装期三钩子：preinstall 先行、install 居中、postinstall 收尾，顺序确定、工作目录为包自身、拿到完整 shell 环境；
• 合法与恶意脚本机制无别，区别只在内容——"这个包凭什么需要安装脚本"是第一审计问句；
• 审计三步：看声明、看内容、看行为（ignore-scripts 加前台重建），流程固定可交接；
• ignore-scripts 是通用止血开关，团队要保证它是可用的；
• 策略二选一：默认放行加抽查，或默认禁止加白名单，按攻击面与流程成本权衡，第六章并入攻防全景。

脚本机制里最庞大的一支用户是原生模块——下一节勘验它们为什么要现场编译、预编译分发如何绕开编译、以及编译失败时的标准排查路径。