FrankenPHP二进制构建时固化环境变量，APP_ENV等必须在frankenphp build前通过shell前缀显式设置，.env仅构建期读取一次；运行时无法覆盖已编译的框架配置。
构建时环境变量怎么传给 FrankenPHP 二进制
FrankenPHP 独立二进制在 frankenphp build 阶段就固化了所有环境变量的解析结果，不是运行时读取 .env 或 ENV。也就是说，APP_ENV=prod 这类值必须在构建前设好，且会被框架（如 Laravel/Symfony）编译进缓存文件，最终嵌入二进制。
常见错误现象：本地 .env 改了 APP_URL，但打包后访问还是旧域名——因为构建时 php artisan config:cache 已把旧值写死进 bootstrap/cache/config.php，而该文件被一并打包进二进制。
- 构建前必须显式设置环境变量：
APP_ENV=prod APP_DEBUG=false APP_URL=https://myapp.com frankenphp build --output myapp - 不要依赖
.env文件本身被读取——它只在构建过程中起一次作用；构建完成后删掉.env也不影响二进制行为 - 若用 Docker 构建，确保
ENV指令或build-args正确透传到构建命令执行环境，而非仅容器运行时
运行时还能改环境变量吗
不能动态覆盖已编译的框架配置，但部分变量仍可被运行时识别——前提是框架代码里没做「编译期固化」。比如 $_SERVER['APP_ENV'] 在 PHP 脚本里直接读取是有效的，但 Laravel 的 config('app.name') 会走缓存，返回构建时的值。
容易踩的坑：以为加 APP_ENV=staging ./myapp 就能切环境，结果路由、缓存、日志行为全不对。
立即学习“PHP免费学习笔记（深入）”；
- 仅对纯 PHP 层逻辑有效：比如自定义
if ($_SERVER['APP_ENV'] === 'dev') { ... } - 框架配置类（
config/*.php）、路由缓存、视图预编译等，全部锁定在构建时刻 - 如果真需要运行时切换，得把可变部分抽出来：用
file_get_contents('public/config.json')加载，或通过 HTTP 请求拉取远程配置
--php-ini 和环境变量的关系
--php-ini 参数只影响 PHP 解释器本身的配置项（如 memory_limit、extension_dir），不改变应用层的 $_ENV 或 getenv() 返回值。它和 .env 是两套系统。
典型误用：用 --php-ini custom.ini 试图让 getenv('DB_HOST') 变成新值——这完全无效，custom.ini 里没法定义环境变量。
-
--php-ini只接受标准 php.ini 格式，支持extension=、date.timezone=等指令 - 想注入环境变量，只能靠系统级方式：
DB_HOST=127.0.0.1 ./myapp（但注意上述框架缓存限制） - 在 Docker 中，用
environment:或-e传入的变量，效果等同于 shell 前缀，同样受构建时固化逻辑制约
Worker 模式下环境变量更新为何不生效
Worker 模式进程常驻内存，$_ENV 和 getenv() 在启动那一刻就被快照，后续修改环境变量（比如重载 systemd service 文件）不会刷新已加载的 PHP 类或配置。
这不是 FrankenPHP 的 bug，而是 PHP 运行时机制决定的——类定义、配置数组、路由映射一旦加载进内存，就不会重新解析环境。
- 改了
.env或系统ENV？必须重建二进制 + 重启进程 - 临时调试可用
putenv('APP_DEBUG=true')，但仅对当前请求有效，且无法影响已初始化的框架服务（如 DB 连接池） - 真正需要热变更的配置，建议走外部存储（Redis / JSON 文件 / Mercure 推送），而不是依赖环境变量
