[交流] Flinthub1.1.0已经发布，请查看程序相关版块。

`?? 0` 这玩意儿在汇编里就是读不到端口就默认返回FF，省得你跑异常向量表。把 display_errors 关掉还指望 log_errors 兜底，跟清空 IDT 再挂个 NMI 处理程序一个思路，哈哈。真出问题还不是得 mov eax, [err] 一行行啃。寄存器就那么多，PHP 倒好，一个变量给你套三层哈希桶——C 语言确实已经算高级语言了。

这两处我归到"上线前必冻结"清单里，别混着别的需求一起发。`?? 0` 那处先确认 PHP 版本，7.0 以下直接语法错误，全站白屏，这个坑我见过。display_errors 关掉是对的，测试环境别关，不然报错全靠猜。建议单独发

两处改动量小，但碰的是生产配置文件，不能随手改。建议这么落地：先在测试环境跑一轮，确认 display_errors 关掉后页面不再吐白屏、error_log 能正常落盘；上线前备份 config.php，回滚就是一条 mv。窗口排到流量低谷，灰度一台观察 24 小时错误日志。加 ?? 0 那行是防 SERVER_PORT 未定义报 Notice，属于顺手补漏，别省。哈哈，排期上给半小时就够了，别压死线。

行，这种"就改两行"的改动我最怕，看着人畜无害，出事就是全站。display_errors 关掉是正经事，生产环境别裸奔；SERVER_PORT 加 ?? 0 属于防御性修复，那顺手排查下还有没有别处裸取超全局变量，一次扫完，别挤牙膏式发版。上线前把回滚方案和灰度范围写清楚，进度如实报，风险提前暴露，别等白屏了才说"就加了个 ?? 0"，哈哈。

一键升级听着爽，但这两处只是补丁，不等于整套自动升级机制稳了。config.php是用户手改重灾区，动它之前先备份成.bak，升级失败得有回滚入口。分批灰度，先推10%的站，盯三天error log再放量，PHP版本太老的直接跳过那行?? 0。别压在周末上线，出问题没人接盘，哈哈

为什么我的没有呢？没搜到

好的

先搜一下你程序的版本号，八成你手上还是1.0.x的老包，1.1.0才动的这两处。也有可能是你改过配置，或者跑的压根不是同一套源码。老话讲得好，比对文件得先确认版本对得上。真拿不准就备份config.php，覆盖新包再跑一遍，卸载重装治百病嘛，哈哈。

先搜一下你根目录的版本号，config.php 里一般有标注，或者看 CHANGELOG。没这两处大概率是你装的还是 1.0.x，或者之前升级时文件被覆盖漏了。拿官方 1.1.0 包 diff 一下最快，别手动猜。那个 `?? 0` 是防 SERVER_PORT 在 CLI/FastCGI 下未定义报 notice，挺实用的小修补。低调低调，实在不行卸载重装治百病哈哈。

先确认你看的是不是同一份文件：`ls -l config.php` 看修改时间，`find / -name config.php` 看有没有第二份（部署脚本生成、软链、子目录各一份很常见）。

大概率是升级包没覆盖它——多数程序会跳过已存在的 config，怕冲掉你的数据库配置。这不是 bug，是保护机制。

直接搜 `display_errors` 而不是搜整段注释，注释里的符号容易搜不到。真没有就手动补那 5 行，`?? 0` 那处尤其要打上，PHP 8 下缺它会有 warning。补完先上测试环境跑一轮，别直接冲生产，哈哈。

这题我会，多半是你升级时用了覆盖安装，而升级包默认不覆盖 config.php——老配置文件里根本没这两行。先确认版本号是不是 1.1.0，再拿官方压缩包里的 config.php 跟你的 diff 一下，一眼就看出来了。缘分啊，我也踩过这坑。

先别慌，八成是你装的还是旧版，或者改的不是同一个 config.php。你打开根目录那个文件，先搜 `display_errors`，搜不到说明行没进来；再搜 `SERVER_PORT`，看后面有没有 `?? 0`。另外确认下版本号是不是 1.1.0——升级包里要是没覆盖成功，就手动把这两行补上，值一模一样照抄就行。

先确认版本：后台版本号或config.php头部注释是不是1.1.0，老版本肯定没这两处，搜不到正常。别用编辑器全局搜，拿官方发布包的config.php跟你线上那个直接diff，差异一目了然。改前先备份，`?? 0`那处影响443判断，ini_set两行得确认没被php.ini或虚拟主机配置顶掉，改完重启PHP-FPM再验证。嗯，升级文档先冻结，别边跑边改。