各位来宾，各位未来的 PHP 开发者，大家好。
欢迎来到这场关于“大扫除”的讲座。如果你以为 PHP 8.4 的 JIT（即时编译）优化已经让我们轻装上阵了，那你就大错特错了。我们今天聚在这里，是为了探讨一个严肃的话题：如何给 PHP 的灵魂做一次彻底的透析手术，剔除那些寄生在内核深处、像死皮一样顽固的物理包袱。
想象一下，你穿着一身在这个时代很潮的机能风衣服，但你的背包里却塞满了十年前淘汰的磁带、诺基亚 3310 和过期的泡面。你跑起来会非常快吗？不，你会被绊倒。
PHP 9.0 就是这样一场关于“断舍离”的革命。Rasmus Lerdorf（PHP 之父）如果还在世，估计早就拿把大锤把这些过时的机制砸个稀巴烂了。今天，我们就来聊聊，在 PHP 9.0 中，哪些过时的内核机制必须被彻底移除。
准备好了吗？让我们开始清理代码仓库的垃圾堆。
1. create_function：来自 PHP 4 的幽灵
首先，我们要清理的是Eval 的亲兄弟。在 PHP 7.2 中，create_function 已经被标记为废弃，但它像僵尸一样赖着不走。到了 PHP 9.0，它必须下地狱。
为什么它是包袱？
create_function 是 PHP 4 时代为了支持动态匿名函数而留下的“缝合怪”。它的内部实现是使用 eval() 函数，将用户传入的字符串拼接到代码中。这就像是你在金库门口写了一个脚本，告诉保安：“如果有人输入密码，你就把金库打开。” 然后你把这个脚本粘贴到了墙上，让所有人都能看到。这不安全，简直是灾难。
代码示例：曾经的“优雅”
// PHP 5 时代的写法，开发者觉得很方便
$func = create_function('$x, $y', 'return $x + $y;');
echo $func(10, 20); // 输出 30内部机制分析：
在 Zend 引擎的内部，当调用 create_function 时，内核实际上会做如下操作（伪代码）：
void* create_function(const char *args, const char *body) {
char *code = emalloc(strlen(body) + strlen(args) + 64);
sprintf(code, "function(%s) { %s }", args, body);
zend_eval_string(code, NULL, "created by create_function");
// ... 创建一个类实例，绑定闭包 ...
return closure;
}看，看到了吗？zend_eval_string。这不仅是包袱，这是炸弹。
9.0 的终极裁决：
在 PHP 9.0 中，调用 create_function 会直接抛出致命错误。
你应该怎么写？
// PHP 9.0 正确姿势
$func = fn($x, $y) => $x + $y;
echo $func(10, 20); // 依然输出 30我们要让那些还在用 create_function 的老旧代码库在编译阶段就死掉。这就是物理包袱清理的第一步：让动态代码执行彻底消失在语法糖层面。
2. list() 语法糖：手动解构的累赘
接下来，我们要讨论的是 list()。这个函数在 PHP 7.0 之后就变得很尴尬了。它在数组解构时表现得像个不懂事的搬运工，完全忽略数组的键，只管把值扔给变量。
为什么它是包袱？
list 的存在是因为早期没有解构语法。但现在我们有 [ ... ] 了。list() 是一种“手动解构”，它强制你在左边写变量名，右边写数组。这不仅啰嗦，而且容易出错。
代码示例：list 的调皮行为
$arr = [1 => 'a', 2 => 'b'];
// 注意，这里忽略了键 1，直接跳到了 2
list($x, $y) = $arr;
// $x 是 'b', $y 是 null
var_dump($x); // string(1) "b"
var_dump($y); // NULL这简直是语义混乱的巅峰！你明明给了它一个数组，它却像个偏执狂一样只关心索引。
9.0 的终极裁决：
在 PHP 9.0 中，list() 将被彻底移除。
你应该怎么写？
$arr = [1 => 'a', 2 => 'b'];
[$x, $y] = $arr;
var_dump($x); // string(1) "a"
var_dump($y); // string(1) "b"这才是真正的解构。数组键被保留，赋值被尊重。把 list() 留在 PHP 9.0 里，就像是在现代婚礼上坚持穿着燕尾服跳街舞一样，既不合适又多余。
3. extract()：命名空间的噩梦
extract() 函数在早期的 PHP 开发中非常流行，人们喜欢把请求参数数组直接 extract 出来变成变量。
为什么它是包袱？
这违反了“最小惊讶原则”。如果你有一个变量叫 $mode，而你又从某个不可信的来源 extract 了一个变量叫 mode（注意大小写），你的变量会被覆盖。更糟糕的是，它会导致命名空间冲突，攻击者可以通过精心构造的数组键注入任意变量。
代码示例：被覆盖的变量
$superglobal = ['password' => '123456', 'user' => 'admin'];
extract($superglobal);
// 现在你的 $password 变量被污染了
// 攻击者注入了 'admin' 变量
// 并且可能注入了其他隐藏变量
echo $password; // 123456
echo $user; // admin9.0 的终极裁决：
PHP 9.0 将直接移除 extract() 函数。如果你需要把数组元素变成局部变量，请使用 foreach 或显式的赋值。
foreach ($_GET as $key => $value) {
$$key = $value; // 谨慎使用，但这比 extract 安全可控
}我们要禁止这种“魔术操作”。让代码的意图显式化，不要让变量凭空出现。
4. == 宽松比较的“魔法转换”
这是 PHP 内核中最沉重的包袱。虽然 PHP 8.0 引入了严格类型，但在 == 和 != 比较中，依然存在大量的类型强制转换逻辑。
为什么它是包袱？
== 是个骗子。它会试图把你手里的一堆不同的牌（数据类型）强行凑成一副牌（相同类型）。
1 == "1a"是真的吗？不，但在==眼里是真的。[] == null是真的吗？是的。0 == "foo"是真的吗？是的。
这种隐式转换不仅性能糟糕（内核需要不断检查类型并执行转换），而且极其容易引发逻辑 bug。
代码示例：== 的欺骗
function checkUser($id) {
if ($id == 0) {
return "User ID is 0";
}
return "User ID is " . $id;
}
echo checkUser("0"); // 输出: User ID is 0
echo checkUser(false); // 输出: User ID is 0
echo checkUser(""); // 输出: User ID is 0开发者很容易被这种“宽容”的机制误导，认为数据是干净的，但实际上数据已经被悄悄改变了。
9.0 的终极裁决：
PHP 9.0 将收紧 == 的行为。虽然完全禁止转换很难（因为很多遗留代码依赖它），但我们将移除那些最离谱的“自动类型提升”。
最严重的改动：
移除字符串到数字的自动转换（在非数字字符串比较时，不再是 0）。
你应该怎么写？
if ($id === 0) {
return "User ID is exactly 0";
}这不仅仅是清理包袱，这是在维护代码的尊严。强迫开发者显式处理类型转换，是写出健壮代码的前提。
5. stristr 与 stristr 的语义悖论
这是一个非常有趣的包袱，存在于函数命名和返回值之间的矛盾。
为什么它是包袱？
stristr 的名字告诉你：“这是一个不区分大小写的字符串查找函数”。但是，它的返回值逻辑却充满了矛盾。
strstr("hello", "l")返回 “llo”（从第一个 ‘l’ 开始）。stristr("hello", "l")也应该返回 “llo”，因为它是不区分大小写的。- 但是，
stristr("hello", "L")（大写 L）也返回 “llo”。
如果没找到呢？
strstr("hello", "z")返回false。stristr("hello", "z")返回false。
看起来没问题？不对。
strstr("hello", "l") 返回一个字符串（有值）。
stristr("hello", "z") 返回 false。
等等，false 是字符串吗？
stristr 的文档说：如果没找到，返回 false。
但是，stristr 是不区分大小写的，这意味着它如果找到了 “L”，它会返回字符串。
所以，如果你不知道你要找的字符是 “l” 还是 “L”，你就无法判断函数的返回值到底是找到了（字符串）还是没找到（布尔值）。
这简直是逻辑上的自相残杀。为了区分大小写，我们有了 strstr 和 stristr；但为了不区分大小写，我们让 stristr 返回 false。这违背了函数的命名初衷。
9.0 的终极裁决：
PHP 9.0 将废弃 stristr，只保留 strstr。
为什么？因为 strstr 的行为是明确的：找不到就返回 false。stristr 的存在只是增加了脑力负担。如果用户想要不区分大小写，他们用 stripos 查索引，或者用 stristr（虽然会被废弃）。我们不需要两个名字相似、行为却像黑洞一样的函数。
// 废弃
$part = stristr("hello", "L");
// 9.0 推荐
$part = strstr("hello", "L"); // 明确，直接6. require_once / include_once 的内核开销
最后，我们要清理的是 PHP 核心加载器上的“牛皮癣”。
为什么它是包袱？
在 PHP 5 时代，每次加载一个文件，内核都要去检查一个哈希表，看看这个文件是不是已经被加载过了。
require_once 告诉内核：“兄弟，帮我看看这文件以前没见过吧？”
性能分析：
每次加载，即使文件没变，内核也要：
- 获取文件路径的 MD5 哈希。
- 查找哈希表。
- 如果没找到，加载文件。
- 如果找到了，跳过。
- 更新哈希表。
在 PHP 8.4 的 JIT 时代，这种昂贵的文件系统操作简直是慢动作回放。
代码示例：加载器的负担
// 即使文件里只有一行 echo "Hello";
// PHP 内核依然要检查它的“前世今生”
require_once 'config.php';
require_once 'config.php';
require_once 'config.php'; 9.0 的终极裁决：
PHP 9.0 将移除 require_once 和 include_once。
随着 Composer 的普及和 PSR-4 自动加载器的完善，我们的项目几乎不再需要 require_once。每一个类名都被唯一映射到一个文件路径。
从 PHP 9.0 开始，如果再写 require_once，你会得到一个语法错误。
你应该怎么写？
使用 Composer 的 vendor/autoload.php。这是现代 PHP 的生命线，而不是 require_once 这种土办法。
// 废弃
require_once 'Database.php';
// 9.0 推荐
use Database;
// 自动加载器会处理一切7. mysql_ 扩展：永远的幽灵
虽然 mysql_ 扩展早在 PHP 7.0 就已经被移除了，但在讨论“包袱”时，它依然是一个幽灵，因为它是那个永远存在的恐惧。
为什么它是包袱？
即使内核已经不包含 mysql_ 的代码，但在 C 扩展开发的文档中，依然有人引用它。它代表了 PHP 早期“拿来主义”的糟糕风格——没有预处理，没有类型安全，只有直接连接。
9.0 的终极裁决：
PHP 9.0 的内核文档中将彻底抹除关于 mysql_ 扩展的所有引用。我们将不再维护针对该扩展的任何兼容层。如果有人想用 MySQL，他们必须使用 PDO 或 mysqli。
8. foreach 的引用语义遗留
这是一个非常深层、非常隐晦的包袱。
在 PHP 7.0 之前，foreach ($array as &$value) 的行为非常奇怪。一旦循环结束，$value 变量会保留对数组最后一个元素的引用。你需要手动 unset($value) 来释放它，否则它会在后续代码中导致无限循环或变量污染。
虽然 PHP 7.4 已经修复了 $value 变量的销毁问题，但 foreach 的引用行为在某些边缘情况下依然让开发者摸不着头脑。
代码示例：引用的陷阱
$arr = [1, 2, 3];
foreach ($arr as &$val) {
$val = $val + 1;
}
// 如果忘记 unset($val)
$arr[] = 4;
var_dump($arr); // PHP 7.4+ 中：[2, 3, 4, 4] (bug 消失了)
// 但在更早的版本中：[2, 3, 4, 3] (无限循环的错觉)9.0 的终极裁决：
PHP 9.0 将简化 foreach 的引用处理逻辑。在遍历引用时，PHP 将不再产生“悬空引用”的风险。我们不再需要开发者背诵 unset($val) 的口诀。这又是一个减少心理包袱的胜利。
结语：清理后的未来
各位，PHP 9.0 的到来不仅仅是版本号的升级，它是一场外科手术。
我们移除 create_function，是为了代码的安全性；我们移除 list()，是为了语法的清晰度；我们移除 extract()，是为了防止变量污染；我们移除 require_once，是为了加载器的效率。
这些过时的内核机制，就像是旧时代的化石。它们证明了我们曾经是多么的笨拙、多么的不安全、多么的低效。但既然我们已经学会了 fn() 闭包，学会了解构数组，学会了使用 Composer，为什么还要背着石头跑马拉松呢？
物理包袱清理，就是为了让 PHP 的未来跑得更快、更稳、更干净。
感谢各位的聆听，愿你们的代码永远没有 require_once，永远不使用 create_function，永远使用 ===。下课！