为何GitHub文档中$GITHUB_ENV与$GITHUB_OUTPUT有时加引号？

为什么文档里引号时有时无？ #

这本质是Shell 变量展开的规则问题，和 GitHub Actions 本身无关，完全是 Bash（或其他 POSIX Shell）的语法要求。核心原因在于变量值是否包含特殊字符：当变量值里有空格、制表符、换行符，或者 *、? 这类通配符时，不加引号会触发 Shell 的分词或路径扩展，导致变量被错误解析。

比如如果 GITHUB_ENV 的路径是 /tmp/my env file（带空格），不加引号的话，Shell 会把它拆成 /tmp/my、env、file 三个部分，执行 echo ... >> $GITHUB_ENV 就会报错找不到文件。

什么时候必须加引号？ #

• 变量值不确定或可能包含特殊字符时：比如用变量动态生成环境变量名/值的场景（像文档里的 echo "{environment_variable_name}={value}" >> "$GITHUB_ENV"），或者你不确定 GitHub 会不会在未来修改这些变量的路径（比如加空格），加引号能避免潜在问题。
• 遵循 Shell 最佳实践：专业 Shell 脚本里，几乎所有变量引用都应该加双引号，这是避免意外分词和扩展的标准做法。GitHub 文档里对 GITHUB_OUTPUT 始终加引号，就是在贯彻这个最佳实践。

为什么不加引号有时也能运行？ #

因为当前 GitHub Actions 环境中，GITHUB_ENV 和 $GITHUB_OUTPUT 的路径都是无特殊字符的单一路径（比如 /home/runner/work/_temp/_runner_file_commands/set_env_xxxx），所以不加引号时 Shell 不会出错。但这只是当前环境的巧合，不是语法上的正确写法。

总结 #

稳妥起见，所有场景都给 $GITHUB_OUTPUT 和 $GITHUB_ENV 加双引号，既符合 Shell 最佳实践，也能避免未来环境变化导致的问题。文档里的无引号示例只是简化写法，适合演示静态、无特殊字符的场景，但生产脚本不建议这么写。

内容的提问来源于stack exchange，提问作者Chrᴉz remembers Monica