json_decode在PHP 8.0中未被移除，而是强制内置；报错主因是disable_functions配置、双php.ini环境差异或Alpine系统未安装php8-json扩展。
json_decode 函数在 PHP 8.0 中绝对存在，且比以往更稳定——它不是被移除，而是随 json 扩展一起被强制内置，无法编译关闭。
如果你调用 json_decode 报错（比如 Fatal error: Uncaught Error: Call to undefined function json_decode()），问题一定出在运行时配置或环境隔离上，而不是函数本身消失了。
为什么 Web 页面里找不到 json_decode，但 CLI 下能用？
这是最典型的“双 php.ini”陷阱：Web 服务器（如 Apache/Nginx + PHP-FPM）和命令行（php -r）加载的是完全不同的配置文件。
检查方式很简单：
立即学习“PHP免费学习笔记（深入）”；
- Web 端新建
info.php，写<?php phpinfo(); ?>，浏览器打开后搜索Loaded Configuration File，记下路径 - CLI 端执行
php --ini，看Loaded configuration file是哪个 - 对比两个文件是否一致；不一致就说明你改了其中一个，却以为全局生效
常见错误：只在 CLI 的 php.ini 里启用了 extension=json，但 PHP-FPM 用的是另一份配置，里面没开——或者更糟，写了 disable_functions = json_encode,json_decode。
disable_functions 是真凶，不是 json 扩展没装
PHP 8.0+ 的 json 扩展无法卸载，但你可以用 disable_functions 把它的函数一个个“锁死”。这个配置项优先级极高，一旦命中，json_decode 就会直接报“undefined function”。
排查步骤：
- 在出问题的环境中执行
php -i | grep disable_functions或查phpinfo()页面里的 “Disable Functions” 行 - 如果输出包含
json_decode或json_encode，立刻删掉——别犹豫 - 注意：这个设置可能出现在主
php.ini、www.conf（PHP-FPM）、甚至.user.ini里，得逐个翻
特别提醒：某些 Docker 镜像（尤其是 Alpine）默认启用 disable_functions 锁一堆函数，不单是 json 相关的。
Alpine Linux 下必须显式安装 php8-json
Alpine 的包管理策略是“最小化”，哪怕 PHP 8 已内置 json，它的 apk 包也把 json 拆成独立扩展包。只装 php8 不装 php8-json，json_decode 就不可用。
Dockerfile 正确写法：
apk add php8 php8-json php8-opcache
验证是否生效：
php -r "echo json_encode(['test' => 1]);"
如果报错或无输出，说明扩展没加载成功。此时再查 php -m | grep json，空结果就是没装对。
Composer autoload 阶段就挂了，根本看不到错误详情
有些老项目在 composer autoload 过程中就调用 json_decode（比如解析 composer.json 或插件元数据）。此时若 disable_functions 已生效，autoload 会静默失败，后续所有类都加载不了——你看到的可能是 Class not found，但根源是 json_decode 被锁死了。
调试方法：
- 临时注释掉
vendor/autoload.php引入，改用php -r "var_dump(function_exists('json_decode'));"单独验证 - 或在项目入口加一行：
if (!function_exists('json_decode')) { die('json_decode missing'); }
这种场景下，phpinfo() 都来不及输出，就得靠前置探测。
真正的麻烦点往往不在“有没有扩展”，而在于“谁在运行时把它拦腰砍断”。disable_functions、多配置文件、Alpine 包拆分，这三处最容易让人反复怀疑自己是不是装错了 PHP 版本。
