php 8.3 扩展开发必须使用官方 php sdk 搭建对应 8.3 分支的构建环境，windows 用 vs2019（vs16），linux/macos 需 clone php-src 的 php-8.3 tag 并执行 ./buildconf --force；直接复用旧版代码或仅装 php-dev 会导致编译失败。
PHP 8.3 扩展开发必须用 PHP SDK，不能直接拿旧版代码编译
PHP 8.3 的内部 API 有实质性变动，尤其是 ZTS（线程安全）模型、对象存储结构、zend_string 处理逻辑和常量表注册方式。直接把 PHP 7.x 或 8.0–8.2 的 C 扩展源码丢进 8.3 环境里 phpize && configure && make，几乎必然失败——不是报 unknown type name 'zend_object_handlers'，就是卡在 zend_register_internal_class_ex 参数不匹配。
正确路径只有一条：用官方 PHP SDK 搭建构建环境，且必须对应 8.3 分支。Windows 下要用 Visual Studio 2019（vs16），Linux/macOS 下则依赖 php-src 的完整源码树和 buildconf 生成的配置系统。
- Windows：必须运行
phpsdk-vs16-x64.bat，再执行phpsdk_buildtree phpdev；否则phpize生成的 configure 脚本会漏掉 ABI 兼容性检查 - Linux/macOS：不能只装
php-dev包，要 clone 官方php-src仓库的php-8.3tag，并确保./buildconf --force成功后再进扩展目录 - 所有扩展的
config.m4必须显式声明PHP_ARG_ENABLE和PHP_NEW_EXTENSION，且第二个参数必须是扩展名小写（如redis），否则make install后extension=加载失败
phpize 生成的 configure 脚本在 PHP 8.3 中默认禁用 ZTS 支持
如果你的扩展需要在 Apache mpm_winnt 或 Nginx + PHP-FPM 的多进程/线程混合模式下运行（比如某些共享内存或信号处理逻辑），就必须启用 ZTS。但 PHP 8.3 的 phpize 默认不带 --enable-zts，它生成的 configure 脚本也不会识别这个参数——强行加会导致 configure 报错 “unrecognized option”。
解决办法不是改 phpize，而是绕过它：进入扩展源码根目录后，手动执行：
php -r "echo PHP_BINDIR;" | xargs -I {} cp {}/php-config ./
./configure --with-php-config=./php-config --enable-zts
注意两点：
-
php-config必须来自你实际要部署的 PHP 8.3 安装（CLI 或 FPM 版本），不能用系统自带旧版的 -
--enable-zts是传递给扩展自身的编译逻辑，不是传给 PHP 主干；扩展代码里需用#ifdef ZTS包裹线程局部存储（TLS）相关调用，例如TSRMLS_DC已被移除，改用zend_thread_safe宏或zend_get_current_thread_id()
扩展中访问类常量、属性、方法必须用新版 Zend API
PHP 8.3 强化了只读属性（readonly）和接口常量类型约束（如 const string php = '8.3';），这直接影响扩展里用 C 代码读取用户定义类行为的方式。老写法如 zend_read_property 直接读 zend_object 的 properties_table 数组，在 8.3 中可能返回 NULL 或触发 fatal error。
必须改用以下方式：
- 读类常量：
zend_get_constant_str("MyClass::MY_CONST", sizeof("MyClass::MY_CONST") - 1)，不能靠zend_hash_find查ce->constants_table - 读 public 属性：
zend_read_property仍可用，但第三个参数（silent）建议设为1避免 warning；若属性是readonly，需先判断property_info->flags & ZEND_ACC_READONLY - 调用方法：
zend_call_method_with_0_params等函数签名未变，但传入的zval *object必须已初始化（Z_TYPE_P(object) == IS_OBJECT），否则 PHP 8.3 会直接 abort
加载顺序和 zend_extension 冲突比以前更敏感
SourceGuardian 和 ionCube 这类商业 loader 都依赖 zend_extension，而它们和你自己写的扩展共存时，顺序错了就直接导致 PHP 启动失败（Segmentation fault 或 zend_mm_heap corrupted）。PHP 8.3 的模块加载器对 module_number 和 post_deactivate_func 执行顺序做了更严格的校验。
关键规则：
- 所有
zend_extension（包括你的自研扩展）必须放在php.ini中所有extension=行之前 - 多个
zend_extension之间，ionCube 必须最前，SourceGuardian 次之，你的扩展最后——因为 ionCube 会 patch opcode handler，SourceGuardian 依赖其 patch 后的结构，而你的扩展最好在两者都初始化完后再介入 - 验证是否生效：运行
php -m时，ionCube和SourceGuardian必须出现在输出开头几行；若你的扩展名出现在它们前面，说明 ini 加载顺序错了
真正麻烦的是调试阶段：一旦 segfault，gdb 里看到的栈帧经常卡在 zend_do_fcall_common_helper 或 zend_mm_alloc_small，其实根源只是 ini 里一行位置放反了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
