Swoole在Windows/Linux/Docker等环境下无法读取环境变量，因其子进程隔离机制导致getenv()失效，应通过启动前显式设置、使用$_SERVER兜底、配置文件硬编码或挂载文件等方式解决。
Windows下Swoole无法读取环境变量
Swoole进程启动时默认不继承父进程的环境变量，尤其在Windows服务模式或通过命令行非交互式启动时，$_ENV 和 getenv() 常返回空。这不是PHP配置问题，而是Swoole子进程隔离导致的。
实操建议：
- 启动前显式注入：在运行
php server.php前，用set SWOOLE_ENV=production（CMD）或$env:SWOOLE_ENV="production"（PowerShell）预设 - 代码中改用
$_SERVER兜底：Swoole会把部分环境变量自动映射到$_SERVER，优先检查$_SERVER['SWOOLE_ENV']而非getenv('SWOOLE_ENV') - 避免依赖
.env文件自动加载：Dotenv类库在Swoole常驻进程中只生效一次，后续reload不会重载，应改用配置中心或启动时一次性解析后存入全局常量
Linux/macOS中Swoole Worker进程丢失环境变量
使用systemctl、supervisord或nohup启动Swoole时，Worker子进程往往拿不到Shell里设置的变量，因为init进程不传递用户会话环境。
实操建议：
- 在systemd服务文件中用
Environment=SWOOLE_ENV=prod或EnvironmentFile=/etc/swoole.env显式声明 - supervisord配置里加
environment=SWOOLE_ENV="prod",PATH="/usr/local/bin:%(ENV_PATH)s"，注意%(ENV_*)语法仅支持继承父进程已有变量，不能新增 - 禁止在
onWorkerStart回调里调用putenv()：该函数只影响当前协程线程，且PHP 8.1+已废弃，Swoole 5.x起Worker内putenv()无效
不同Swoole版本对getenv()行为的影响
Swoole 4.8.0+ 默认启用enable_coroutine_env（协程环境变量隔离），开启后每个协程拥有独立环境变量副本；关闭则共享进程级环境。这直接影响微服务间透传配置的可靠性。
实操建议：
- 若需跨协程共享变量（如统一trace_id注入），必须关闭
enable_coroutine_env，并在onWorkerStart中用putenv()设置基础变量 - 若开启协程隔离（推荐），改用
Swoole\Coroutine::getuid()+ 全局数组模拟环境变量存储，例如：$env_cache[Swoole\Coroutine::getuid()]['DB_HOST'] = '127.0.0.1' - 检查实际生效值：在
onReceive里打印var_dump(getenv('SWOOLE_ENV'), $_SERVER['SWOOLE_ENV'] ?? null)，确认哪条路径真正被读取
Docker容器中Swoole环境变量热更新失效
Docker run时用-e传入的变量，在Swoole常驻进程中是静态快照，容器内执行docker exec -e NEW_VAR=value无法动态注入，且kill -USR1 reload也不会重新读取宿主机环境。
实操建议：
- 构建镜像时用
ENV SWOOLE_ENV=dev写死基础变量，运行时仅覆盖关键项（如数据库密码） - 敏感变量走
/run/secrets或挂载configmap为文件，Swoole启动时一次性file_get_contents('/run/secrets/db_password')，避免轮询 - 禁用
docker-compose up --build后直接docker-compose restart期望刷新环境：restart不重建容器，原环境变量仍有效，必须down && up
环境变量不是“设了就生效”的开关，Swoole的进程模型决定了它必须在Worker生命周期起点完成注入——晚一步，整个请求链路就可能读错配置。最稳妥的方式永远是启动命令行参数化 + 配置文件硬编码关键路径，环境变量只做轻量级切换开关。
