别再乱用 putenv 和 getenv 了，搞懂进程边界才不踩坑

写 PHP 脚本时，很多人习惯随手甩一句 putenv('DB_HOST=127.0.0.1'); 然后紧接 getenv('DB_HOST')。表面看顺风顺水，一到生产环境或者切换运行模式，变量要么静默消失，要么意外污染进程池，排查半天才发现是基础认知偏差。这两个函数不是不能用，而是得清楚它们到底在哪片领地里干活。

putenv 往当前进程的操作系统环境变量块里填数据，getenv 只是顺着这个字典把值捞出来。它修改的不是 PHP 内部的数组，而是底层 C 环境的 environ 指针。这意味着改动只对正在运行的这一个进程生效。如果是 Nginx + PHP-FPM 架构，每次请求都会派发不同的 worker 处理，你在请求里 putenv 塞进去的值，下一次请求被调度到其他 worker 时自然查不到。别指望它能像 Redis 一样跨会话持久化，它更像是一份即时生效的临时便签，进程一退，字迹自动消失。

真正值得用的场景其实很垂直。命令行交互时它是轻量级利器。比如执行批量数据处理脚本，不想动代码或重构配置中心，直接在终端前缀写上 putenv('TARGET_ENV=staging'); php batch.php，就能干净地隔离测试数据。再比如在封装旧版 C 扩展或第三方底层库时，对方强依赖系统环境变量读取参数，此时用 putenv 绕开 PHP 层面的繁琐解析反而更顺手。操作时守住三条底线：限定单次任务作用域、执行完毕后立即 unset 释放内存、坚决不在常驻型守护进程里反复覆写。

很多遗留项目喜欢把 putenv 和 $_ENV 混着用，这里藏着一个高频雷区。$_ENV 是 PHP 模块初始化时从操作系统拷贝的一次性快照，后续通过 putenv 写入的变更，$_ENV 不会同步刷新。如果既要读配置又要写回滚逻辑，最佳做法是统一收敛到 getenv() 或 $_SERVER（CGI 模式下会继承父进程环境变量），或者直接废弃手写环境注入，改用 .env 文件搭配标准dotenv实现。现代架构的共识是把环境变量视为不可变契约：部署层负责下发，运行层只读校验，安全审计时也能一目了然追踪源头。

工具本身没有优劣，只有匹配度。摸清进程生命周期的断点，分清临时覆盖与持久配置的界限，putenv 和 getenv 就能稳稳停在该有的位置。写代码就像归置工具箱，知道每样物件的物理属性，上手就不会误伤手指。下次再遇到需要动态调整环境参数的需求，先停顿两秒确认它的流转路径，落笔自然就轻了。