环境变量看起来像一块随手可放东西的地方，但它本质上只适合放少量标量配置。Linux 的 execve() 明确把环境定义成一组 key=value 字符串，且必须以空指针结尾；Python 的 subprocess 也说得更直白，POSIX 下传给新进程的 env 必须是 str 到 str 的映射 [1][2]。这意味着，数组的边界、空元素和顺序，不会被环境变量原样保留下来。

真正容易踩坑的地方，不是 Bash 会不会数组，而是你把“内部数据结构”误当成“进程间传输格式”。Bash 手册 5.3 版当然支持数组，但那是 shell 内部能力，不是进程边界上的通用容器 [3]。一旦数据要跨进程，数组就会先被压扁成字符串，再由下游自己猜边界。

数据快照

man7 对 execve() 的说明给了两个非常关键的边界：一是 envp 只是字符串列表，二是总大小还会受到内核限制。Linux 2.6.23 之前，argv 和 envp 曾受 32 页限制，在 4 KiB 页系统上就是 128 KiB；2.6.23 之后，限制改成和 RLIMIT_STACK 相关，并且还受 3/4 _STK_LIM 约束 [1]。这说明环境变量不仅不能保留数组结构，连体积也不是无限的。

Python 文档同样说明，subprocess.run() 的 env 参数本质上是一个映射，传给子进程时需要按字符串处理 [2]。也就是说，不管你用 Bash、Python 还是别的语言，只要走进程边界，环境变量都更像“配置标签”，而不是“数据容器”。

判断

我的判断是，环境变量最适合放的是少量、稳定、可读的配置，比如开关、路径、账号名和模式位；最不适合放的是数组、嵌套结构、长列表和带空格的参数串。只要你把一组值塞进 env，后面迟早会遇到边界消失、顺序错乱或者长度超限的问题 [1][2]。

这不是 Bash 的缺点，而是设计目标不同。环境变量的职责，是让新进程快速拿到一组简单文本，不是承担复杂对象序列化。你越想拿它当通用容器，越容易在 CI/CD、部署脚本和批处理里吃到反噬。

怎么判断该不该放进环境变量

• 只有一个值、而且它本来就是字符串，适合放 env。
• 只要包含多个元素、空值、顺序要求或嵌套层级，就不该放 env。
• 只要你需要“还原成原样”，就应该先选 JSON、文件或标准输入，而不是 env [2][3]。

现实里最稳的做法很朴素，配置归配置，数据归数据。环境变量负责“告诉下游怎么跑”，数组负责“记录要处理什么”。把这两个角色分开，脚本会少很多玄学错误 [1][2][3]。

参考文献

[1] execve(2) - Linux manual page — man7.org

[2] subprocess — Subprocess management — Python 3.14.4 documentation — Python

[3] Bash Reference Manual, Arrays section — GNU