frankenphp 启动时需 shallow-copy $_server 以绕过 php 内核对超全局变量的写时复制限制，确保后续修改（如 request_uri、https 等键）生效；不拷贝则会导致静默失败、警告或未定义行为。
FrankenPHP 启动时为何要 shallow-copy $_SERVER
FrankenPHP 在进入请求处理循环前执行$_SERVER = $_SERVER（或等效的数组赋值），这不是冗余操作，而是为绕过 PHP 内核对超全局变量的写时复制（Copy-on-Write）限制所必须的“破局动作”。
PHP 的 $_SERVER 在 SAPI 层初始化后，底层 zend_array 结构被标记为「不可修改」（immutable）或受引用保护。后续若在请求循环中直接修改（比如 unset 某个键、追加自定义项），PHP 会静默失败，或触发未定义行为——尤其在 FrankenPHP 这种复用进程、多请求共享同一 PHP 执行上下文的模型里，这种修改需求很常见（如注入路由路径、覆盖 REQUEST_URI、清理敏感头）。
浅拷贝这一步，本质是强制触发 COW：让内核为 $_SERVER 分配一个可写的副本，后续所有写操作才真正生效。
常见错误现象包括：
- 在 FrankenPHP 中调用
unset($_SERVER['HTTP_X_FORWARDED_FOR'])后该键依然存在 - 手动设置
$_SERVER['SCRIPT_NAME'] = '/api/index.php'，但后续$_GET解析或框架路由仍读取旧值 - 使用
putenv()修改环境变量后，getenv('APP_ENV')返回旧值，而$_SERVER未同步更新
哪些 $_SERVER 键在 FrankenPHP 中最常被重写
不是所有键都适合/需要修改，但以下几项在现代 PHP 应用（尤其是基于 PSR-7 或 Symfony HttpFoundation 的）中高频重写：必须重写的典型键：
-
REQUEST_METHOD：用于适配 CLI 或 HTTP/2 推送场景，可能从GET改为POST -
REQUEST_URI：前端控制器模式下需重写为内部路由路径（如/api/users→/index.php） -
SCRIPT_NAME和PHP_SELF：确保__DIR__或框架的路径解析逻辑不因反向代理而错位 -
HTTPS和HTTP_X_FORWARDED_PROTO：修复 TLS 终止后协议感知失效问题
注意：SERVER_ADDR、SERVER_PORT、GATEWAY_INTERFACE 等反映真实运行环境的键，一般不应覆盖，否则会导致日志、健康检查或安全中间件误判。
不 copy $_SERVER 直接改会怎样
在 FrankenPHP 的长期运行进程（worker）中，若跳过浅拷贝直接写$_SERVER：
表现可能因 PHP 版本和构建方式而异，但共性问题是：
- PHP 8.2+：部分写操作抛出
Warning: Cannot modify header information类似提示（即使没调用header()），因为内核检测到不可变数组被非法写入 - PHP 8.1 及更早：静默失败，
var_dump($_SERVER)显示修改未生效，但getenv()或$_ENV可能已变更，造成状态不一致 - 某些 SAPI（如 embed）下触发 segfault，尤其在多次请求后数组结构损坏
这不是 FrankenPHP 的 bug，而是 PHP 核心对超全局变量生命周期管理的硬约束。copy 是目前最轻量、兼容性最好的解法。
实际代码中怎么写才安全
不要依赖$_SERVER = $_SERVER 这种隐式写法；明确 clone 并验证可写性：
// 推荐：显式浅拷贝 + 关键键校验
$_SERVER = array_replace($_SERVER, []);
if (!isset($_SERVER['REQUEST_URI'])) {
$_SERVER['REQUEST_URI'] = '/';
}
// 确保后续可写
$_SERVER['X_CUSTOM_FLAG'] = 'applied';
assert(isset($_SERVER['X_CUSTOM_FLAG'])); // 若断言失败，说明拷贝未生效
避免在循环中反复 copy —— 只需在每次请求入口（如 handle() 开始）做一次。也别用 import_request_variables() 或 extract($_SERVER)，它们会污染作用域且无法控制键名安全性。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
