GitHub Actions中`run: |`多行命令与多run步骤的差异

首先得提个醒：你给出的写法二是语法错误！GitHub Actions的YAML语法规定，每个steps列表项（即单个step）是一个独立对象，不能在同一个step里重复定义run字段，这种写法会直接导致工作流执行失败。正确的「拆分成多个步骤」的写法应该是这样的：

steps:
  - name: Run npm ci
    run: npm ci
  - name: Run npm build
    run: npm run build --if-present
  - name: Run npm test
    run: npm test

接下来对比写法一（单个step内执行多命令）和正确拆分的多step写法的核心差异：

1. 错误终止逻辑完全不同 #

• 写法一中的三个命令是在同一个bash脚本里执行的，默认行为是：哪怕前面的命令报错（比如npm ci安装依赖失败），后面的npm run build和npm test依然会继续执行。如果想让脚本遇到错误就立刻终止，需要在脚本开头加上set -e，比如：

  run: |
    set -e
    npm ci
    npm run build --if-present
    npm test
  

• 而多step写法遵循GitHub Actions默认规则：只要某个step执行失败（返回非0状态码），整个job会立刻停止，后续所有步骤都不会执行。比如npm ci的step失败后，build和test步骤会直接被跳过，避免做无用功。

2. 日志可读性与调试效率差异 #

• 写法一的所有命令输出会合并在同一个step的日志中，排查问题时需要在一大段日志里定位对应命令的输出，效率较低。
• 多step写法的每个命令都有独立的日志块，每个step的名称会作为日志标题，哪个步骤失败了一眼就能识别，调试起来更清晰。

3. 执行环境的隔离程度不同 #

• 写法一的所有命令共享同一个shell进程，比如在npm ci之后临时设置的环境变量（未通过env字段声明），后面的命令可以直接读取到。
• 多step写法的每个run会启动一个新的shell进程，临时设置的环境变量无法跨step传递（但通过env字段声明的全局/step级环境变量、文件系统中的依赖/缓存内容是可以共享的，因为同一个job的所有step都在同一个runner虚拟机上运行）。

4. 配置灵活性差异 #

• 多step写法可以给每个步骤单独配置个性化参数：比如给npm test的step添加continue-on-error: true，允许测试失败但不中断整个job；或者给某个step指定working-directory切换工作路径。这些精细控制在写法一中无法实现，所有命令只能共享同一个step的配置。

内容的提问来源于stack exchange，提问作者Khanh