getenv()是Webman中读取环境变量的唯一可靠方式，因$_SERVER不镜像系统变量、$_ENV默认为空且putenv()仅限当前请求；变量必须由Nginx fastcgi_param、PHP-FPM env[]或Docker注入。
Webman 里读 $_SERVER 变量本身没问题，但真正想取“服务器环境变量”（比如 DB_HOST、APP_ENV）时，$_SERVER 很可能根本没你想要的值——它不是操作系统级环境变量的镜像，而是 Web 服务器透传+CGI 协议拼凑出来的混合体。
为什么 $_SERVER['DB_HOST'] 总是空？
因为 $_SERVER 中绝大多数键（如 REQUEST_URI、HTTP_USER_AGENT）是 CGI 请求信息，不是系统环境变量；只有极少数（如 PATH、HOME）由 Web 服务器显式注入。Nginx + PHP-FPM 默认不透传自定义变量，Apache 也需 PassEnv 显式放行。
-
$_SERVER里大写+下划线命名的项（如MY_VAR）≠ 系统环境变量，只是命名风格像 - Webman 启动后，
$_SERVER就已固化，后续putenv()不会自动同步进去 - PHP-FPM pool 配置里没写
env[DB_HOST] = 127.0.0.1，Nginx 的fastcgi_param DB_HOST ...没配，$_SERVER['DB_HOST']必然不存在
getenv() 是唯一靠谱的读取方式
用 getenv('DB_HOST', true) 强制从原生环境读取，绕过 $_SERVER 和 $_ENV 的干扰。这是 Webman 场景下最稳的选择，无论 Nginx 还是 Apache，只要变量真被注入进 PHP 进程，它就能拿到。
- 别用
getenv('DB_HOST')不带第二个参数——PHP 8.1+ 会警告，FPM 下还可能被禁用 -
$_ENV在 Webman 默认配置中几乎总是空的，因为variables_order通常不含E - 调试时别只信
phpinfo()的 “Environment” 区块，它只反映进程启动快照，不包含运行时putenv()或 Web 服务器动态注入的变量
Webman 中设置环境变量必须走外部配置
Webman 是常驻进程框架，putenv() 只影响当前请求生命周期，重启服务后就失效，完全不适合配置管理。
立即学习“PHP免费学习笔记（深入）”；
- Nginx 用户：在
server或location块里加fastcgi_param APP_ENV "production"; - PHP-FPM 用户：在 pool 配置（如
www.conf）里写env[APP_ENV] = production - Apache 用户：用
SetEnv APP_ENV production+PassEnv APP_ENV，并确认模块已启用 - 容器部署：直接通过
docker run -e APP_ENV=production注入，Webman 启动时自动继承
读取路径和 URL 要避开常见陷阱
Webman 处理伪静态或反向代理时，$_SERVER['PHP_SELF'] 和 $_SERVER['HTTP_HOST'] 容易出错，拼 URL 别硬凑。
- 要原始请求路径（含 query）：用
$_SERVER['REQUEST_URI']，不是$_SERVER['PHP_SELF'] - 要协议+域名：优先判断
$_SERVER['HTTPS'] === 'on'或$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https'，再拼$_SERVER['HTTP_HOST']（不是SERVER_NAME） - 脚本绝对路径：用
$_SERVER['SCRIPT_FILENAME']，它比__FILE__更可靠（尤其在 symlink 场景） - 文档根目录：
$_SERVER['DOCUMENT_ROOT']在 Nginx 下可能为空，建议改用dirname($_SERVER['SCRIPT_FILENAME'])回推
真正关键的不是“怎么读”，而是“变量是否真的进了 PHP 进程”。Webman 不处理环境变量注入，只消费——漏配 Nginx 或 PHP-FPM，getenv() 再准也读不到。
