php.ini 中 extension 加载顺序直接影响扩展行为，openssl、mbstring 等需前置，opcache 必须最后加载；顺序错误会导致 undefined symbol、函数不可用或 Segmentation fault。
php.ini 里 extension 加载顺序真的影响行为
PHP 8.5 并不提供显式的“扩展优先级设置”机制，extension 指令在 php.ini 中的书写顺序，就是实际加载顺序。这个顺序直接影响依赖关系——比如 curl 要用到 openssl，如果 openssl 加载晚于 curl，某些环境（尤其是 Windows 或静态编译版）会报 undefined symbol 或直接跳过 curl 初始化。
- Linux 动态链接通常能兜底，但不是所有符号都可延迟解析；Windows DLL 依赖更敏感
- 扩展间存在隐式依赖：例如
mbstring被xml和json内部调用，应靠前加载 -
zend_extension（如 opcache、xdebug）和普通extension分属不同加载阶段，互不干扰，但 opcache 必须在所有普通扩展之后启用，否则无法缓存其类定义
哪些扩展必须放在前面
不是所有扩展都平等。以下几类建议固定前置，避免运行时奇怪的函数不可用或编码异常：
-
ctype、iconv、mbstring：底层文本处理基石，json、xml、intl都暗中依赖它们 -
openssl：几乎所有网络扩展（curl、soap、ldap）启动时检查其是否就绪 -
zlib：curl、phar、zip默认启用压缩支持，缺它会静默禁用对应功能
典型安全前置块（放在 php.ini 靠前位置）：
extension=ctype extension=iconv extension=mbstring extension=openssl extension=zlib
opcache 必须最后加载，且不能被其他扩展干扰
opcache 是 zend_extension，它在 PHP 启动后期介入 opcode 编译流程。如果它出现在 extension=xxx 行中间，或者被 extension_dir 变更打断，会导致部分扩展的类/函数不被缓存，甚至引发 Segmentation fault（尤其搭配 xdebug 3.3+ 时）。
PHP 8.5.12
下载
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
立即学习“PHP免费学习笔记（深入）”；
- 确保
zend_extension=opcache.so（Linux）或zend_extension=php_opcache.dll（Windows）写在所有extension=行之后 - 不要把
opcache.enable_cli=1和opcache.preload放在它之前——preload 文件若引用了尚未加载的扩展类，会直接 fatal error - 使用
php -m验证顺序：输出中opcache应排在末尾，且没有[Zend Modules]下重复条目
验证加载顺序和依赖是否生效
光看 php.ini 不够，得看 PHP 实际怎么走的：
- 执行
php --ini确认读取的是预期的配置文件 - 用
php -m查看扩展列表，注意顺序（虽不完全等价于加载时序，但已足够预警） - 关键检查点：运行
php -r "var_dump(function_exists('curl_init'));"，如果返回false但curl在-m列表里，大概率是openssl加载太晚 - Windows 下可用
depends.exe打开php-curl.dll，看它是否标记了对libssl-3.dll的硬依赖且该 DLL 已被正确加载
真正容易被忽略的是：PHP 8.5 开始，部分扩展（如 pdo_sqlite）会尝试动态加载 sqlite3 的共享库，此时不仅 ini 顺序重要，extension_dir 路径下的文件名拼写、大小写、版本后缀（.so.0 vs .so）也会影响是否成功绑定——这已经不属于“加载顺序”范畴，但常被误判为顺序问题。
