PHP修改JSON文件必须严格遵循“读取→解码→修改→编码→写回”流程，需检查json_last_error()、文件权限、BOM头及编码，推荐json_decode($json, true)配合array_replace_recursive安全更新。
直接用 file_get_contents + json_decode 读取并修改 JSON 文件内容
PHP 没有“直接编辑 JSON 文件某字段”的内置函数，必须走“读取 → 解码 → 修改 → 编码 → 写回”流程。跳过解码或编码任一环节，都会导致数据损坏或写入乱码。
常见错误现象：json_encode 后写入文件变成空字符串、中文变 \uXXXX、数组变对象（或反之）、结构错乱。
- 务必检查
json_last_error()，尤其在json_decode后——空文件、BOM 头、非 UTF-8 编码都会让解码失败返回null - 修改前先用
is_array()或is_object()确认解码结果类型，避免对null调用数组操作 - 写入时建议加
JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT，否则中文被转义，且无缩进难调试
json_decode 的第二个参数设为 true 还是 false？
这决定后续怎么改数据：设为 true 得到关联数组，用方括号语法修改；设为 false（默认）得到 stdClass 对象，必须用箭头语法。
实际场景中，绝大多数 JSON 配置文件都是键值结构，用数组更直观、兼容性更好（比如 foreach、isset()、array_key_exists() 都原生支持）。
立即学习“PHP免费学习笔记（深入）”；
- 想改
{"user": {"name": "Alice"}}中的 name：用$data['user']['name'] = 'Bob'（true）比$data->user->name = 'Bob'（false）更少出错 - 如果原始 JSON 有同名数字键（如
[{"id":1}, {"id":2}]），两种方式都可遍历，但数组方式支持array_column等函数 - 注意：
json_decode($json, false)返回的对象，不能用isset($obj->missing)安全判断，得用property_exists()
写回文件前必须用 file_put_contents 并检查返回值
写入失败不报错是常见盲区——磁盘满、目录无写权限、父目录不存在，都会让 file_put_contents 返回 false，但脚本继续执行，结果就是 JSON 文件被清空或没更新。
示例关键逻辑：
if (false === file_put_contents($path, $encoded_json)) {
throw new RuntimeException('Failed to write JSON file: ' . $path);
}
- 路径必须是绝对路径或确保当前工作目录正确，相对路径在 CLI 和 Web 下行为可能不一致
- 写入前可先
is_writable(dirname($path))检查目录权限 - 生产环境建议加文件锁（
flock），避免并发写入覆盖
嵌套深、字段动态的场景下，别硬写多层 isset 判断
比如要安全修改 $data['config']['features']['dark_mode']['enabled']，逐层判空既啰嗦又易漏。推荐封装一个递归设置函数，或用 PHP 8.0+ 的空合并链式操作（?->）配合临时变量。
更实用的做法是：先用 json_decode($json, true)，再用 array_replace_recursive 合并补丁数组，而不是手动钻进多层结构。
- 例如只改 dark_mode.enabled，构造
$patch = ['config' => ['features' => ['dark_mode' => ['enabled' => true]]]]，然后$data = array_replace_recursive($data, $patch) - 注意：
array_replace_recursive会覆盖整个子数组，不是“精准定位单个字段”，需确认是否符合业务语义 - 若字段路径不确定（如 key 来自用户输入），务必过滤非法字符（
..、/）、限制层级深度，防止路径遍历或内存耗尽
json_decode 失败；Web 服务器运行用户（如 www-data）对文件所在目录没有写权限，file_put_contents 就静默失败。这两处不排查，其他逻辑再正确也没用。 
