企业官网建设流程全解析

前言

"接口没报错，但数据不对"是排查起来最费劲的一类问题。前端说金额少了一分钱，后端看日志 SQL 查出来的数字完全正确；前端说列表是空的，后端var_dump出来明明有数据；前端说某个字段是字符串，后端看数据库是int类型。双方各执一词，因为看到的根本不是同一个东西——中间隔着一层序列化（serialization）。

PHP 7.4 这个版本在这个问题上有特殊地位。它是 PHP 7 系列的最后一站，很多"上了年纪"的项目就停在这里。它的安全支持已经在 2022 年 11 月结束，因此这些项目通常还带着一串历史包袱：php.ini是从更老的版本一路拷过来的、数据库连接用的是仿真预处理、时间戳和浮点数处理依赖某个早已被改掉的 ini 默认值。

本文按"先分清数据在哪一层变形，再逐层比对"的思路，把 PHP 7.4 老项目接口数据异常的排查流程拆开，并给出一份可以直接运行的对照脚本。

一、先定位变形发生在哪一层

一个接口从数据库到前端至少要穿过四层，每一层都可能改变数据的形态。排查的第一步不是改代码，而是确定"变形点"在哪一层。

判断技巧：先用命令行客户端跑同一条 SQL。如果 SQL 客户端的结果和接口一致，问题在业务层或序列化层；如果 SQL 客户端也不对，问题在更前面。

二、PHP 7.4 上最容易被忽略的六种静默差异

1. 浮点数转字符串的精度由 ini 决定

这是"金额少一分"的头号元凶。PHP 有两个 ini 指令控制浮点数如何转成字符串：precision（用于echo、字符串拼接）和serialize_precision（用于var_export、json_encode、serialize）。它们的默认值在不同年代是不一样的，而老项目的php.ini往往是从 PHP 5.x 时代继承下来的。

<?php ini_set('serialize_precision', '-1'); echo json_encode(['v' => 0.1 + 0.2]), PHP_EOL; // 0.30000000000000004 ini_set('serialize_precision', '17'); echo json_encode(['v' => 0.1 + 0.2]), PHP_EOL; // 0.30000000000000004 ini_set('serialize_precision', '14'); echo json_encode(['v' => 0.1 + 0.2]), PHP_EOL; // 0.3

同一个表达式，三台机器上三个结果。-1表示"用最短且能无损还原的表示"，从 PHP 7.1 起就是默认值；但如果某台机器的php.ini里还写着serialize_precision = 17，输出的 JSON 就会把浮点误差原样暴露给前端。

结论：金额永远不要用浮点数传输，用整数分。这是唯一能彻底绕开这一层的办法。

2. 空数组与空对象的区别

<?php echo json_encode([]), PHP_EOL; // [] echo json_encode(new stdClass()), PHP_EOL; // {} echo json_encode(['a' => []], JSON_FORCE_OBJECT), PHP_EOL; // {"a":{}}

数据库查出来是[]，前端拿到的也是[]，前端代码写的是obj.key，于是报 "Cannot read property of undefined"。这种情况不是 PHP 的 bug，是双方对"空集合该长什么样"没有约定。

3. 数组键的连续性决定它是数组还是对象

<?php echo json_encode([0 => 'a', 1 => 'b']), PHP_EOL; // ["a","b"] echo json_encode([1 => 'a', 2 => 'b']), PHP_EOL; // {"1":"a","2":"b"}

键不连续时json_encode()输出的是对象。这个问题在"用array_filter()过滤后没array_values()"时极其常见：过滤掉一个元素，键就断了，列表接口从数组突然变成对象，前端的.map()直接崩。

4. 数据库驱动取回的类型

PDO连 MySQL 时，如果开了仿真预处理（PDO::ATTR_EMULATE_PREPARES => true），取回来的所有字段都是字符串；关掉仿真用真实预处理，整数才会以int返回。老项目通常开着仿真，所以接口里的id、count全是字符串。

<?php $pdo = new PDO($dsn, $user, $pass, [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_EMULATE_PREPARES => false, // 让驱动返回原生类型 PDO::ATTR_STRINGIFY_FETCHES => false, // 不要强制转字符串 ]);

前端做严格比较时会因此出问题：接口返回"1"，前端写if (res.id === 1)永远为假。

5. 非法 UTF-8 让 json_encode 整体失败

<?php $bad = ['name' => "abc\xB1def"]; var_dump(json_encode($bad)); // bool(false) echo json_last_error_msg(), PHP_EOL; // Malformed UTF-8 characters var_dump(json_encode($bad, JSON_PARTIAL_OUTPUT_ON_ERROR)); // 部分数据 + null

老数据库表如果还是latin1字符集，某一条记录里有一个非 UTF-8 字节，整个接口的 JSON 就会编码失败。如果代码里没检查返回值，直接echo $json，输出就是空字符串——接口返回 200 但 body 为空，前端只能报"解析失败"。

6. 时区没设置

date.timezone未设置时 PHP 会尝试从系统推断，不同机器推断结果不同。同一个time()值，在服务器和容器里格式化出来的时间可能差 8 小时。这不会报错，只会让"创建时间"看起来莫名其妙。

三、代码实战：一份可运行的对照脚本

把下面这段存成dump_layer.php，在处理接口数据的关键路径上插进去，它会同时打印"原始取回值"和"最终 JSON"，一次性把变形点暴露出来。

<?php // dump_layer.php declare(strict_types=1); /** * 分层打印：先看 PHP 层拿到的真实类型，再看序列化后的结果 */ function dump_layer(string $label, array $rows): void { echo str_repeat('=', 12), ' ', $label, ' ', str_repeat('=', 12), PHP_EOL; echo '[驱动层] 逐字段类型' , PHP_EOL; if ($rows === []) { echo ' （空结果集）', PHP_EOL; } foreach ($rows as $i => $row) { foreach ($row as $k => $v) { printf(" 行%d %-10s %-8s %s\n", $i, $k, gettype($v), var_export($v, true)); } } echo '[序列化层] json_encode 结果', PHP_EOL; $json = json_encode($rows, JSON_UNESCAPED_UNICODE); if ($json === false) { printf(" 编码失败: %s\n", json_last_error_msg()); } else { printf(" %s\n", $json); } echo '[序列化层] 空数组与空对象对比', PHP_EOL; printf(" json_encode([]) => %s\n", json_encode([])); printf(" json_encode(new stdClass) => %s\n", json_encode(new stdClass())); printf(" array_filter 后不重排索引 => %s\n", json_encode(array_filter([0 => 'a', 1 => 'b', 2 => 'c'], fn($v) => $v !== 'a'))); printf(" array_filter 后 array_values => %s\n", json_encode(array_values(array_filter([0 => 'a', 1 => 'b', 2 => 'c'], fn($v) => $v !== 'a')))); echo '[序列化层] 浮点表现', PHP_EOL; printf(" serialize_precision=%s 时 0.1+0.2 => %s\n", ini_get('serialize_precision'), json_encode(['v' => 0.1 + 0.2])); echo PHP_EOL; } // 模拟从数据库取回的数据（老项目里字符串型的数字很常见） $rows = [ ['id' => '1', 'amount' => '1999', 'created_at' => '2024-05-03 10:00:00', 'deleted' => 0], ['id' => '2', 'amount' => '0', 'created_at' => '2024-05-03 10:00:01', 'deleted' => 1], ]; dump_layer('升级前：全字符串', $rows); // 模拟规范化之后 $normalized = array_map(static function (array $r): array { return [ 'id' => (int) $r['id'], 'amount' => (int) $r['amount'], 'created_at' => $r['created_at'], 'deleted' => (bool) $r['deleted'], ]; }, $rows); dump_layer('规范化后：原生类型', $normalized); // 非法 UTF-8 的现场 $bad = ['name' => "abc\xB1def"]; printf("含非法字节时 json_encode 返回: %s\n", var_export(json_encode($bad), true)); printf("错误信息: %s\n", json_last_error_msg());

运行结果（在 PHP 7.4 与 PHP 8.0 上都能跑）：

============ 升级前：全字符串 ============ [驱动层] 逐字段类型 行0 id string '1' 行0 amount string '1999' ... [序列化层] json_encode 结果 [{"id":"1","amount":"1999","created_at":"2024-05-03 10:00:00","deleted":0}, ...] [序列化层] 空数组与空对象对比 json_encode([]) => [] json_encode(new stdClass) => {} array_filter 后不重排索引 => {"1":"b","2":"c"} array_filter 后 array_values => ["b","c"] [序列化层] 浮点表现 serialize_precision=-1 时 0.1+0.2 => {"v":0.30000000000000004} 含非法字节时 json_encode 返回: false 错误信息: Malformed UTF-8 characters, possibly incorrectly encoded

这张输出就是一份"证据链"：驱动层显示id是string，序列化层显示过滤后变成对象，浮点显示精度没有收敛。三条全部命中，问题范围立刻收窄。

四、PHP 7.4 的弃用清单，也是隐患清单

PHP 7.4 本身标记了一大批弃用（deprecated），它们在 8.0 被真正移除。老项目如果还带着这些写法，排查数据异常时很容易被报错信息带偏。下表是排查中真会遇到的几条：

其中array_key_exists($key, $object)和implode参数反序这两条最值得注意——它们在 8.0 不是报错而是行为改变，老代码在新版本上会静默地拿到不同的结果。

常见坑点

1. 只比对 SQL 结果，不比对 JSON 输出

❌ 在业务代码里var_dump($row)看到数字是int，就断定接口没问题。

✅ 一定要打印json_encode()之后的字符串，那才是前端真正收到的东西。

2. 用浮点数存金额

❌ 数据库字段是decimal，PHP 里用float接收，19.99 * 100得到1998.9999999999998。

✅ 用整数分存储和传输，只在展示层除以 100 并格式化。

3.array_filter之后忘了array_values

❌json_encode(array_filter($list, $fn))，过滤掉一个元素后接口从数组变成对象。

✅ 一律array_values(array_filter(...))。

4. 不检查json_encode的返回值

❌echo json_encode($data);，遇到非法 UTF-8 时静默输出空字符串，接口 200 但 body 为空。

✅ 用JSON_THROW_ON_ERROR（PHP 7.3+ 可用）配合try/catch，或者至少检查=== false。

5. 从别的机器拷php.ini

❌ 把开发机的php.ini拷到线上，precision、serialize_precision、date.timezone全跟着走。

✅ 显式在php.ini里写死这三项，并在部署脚本里校验。

6. 用==判断接口返回的 ID

❌if ($row['id'] == $input)，字符串"1abc"在旧版本上会等于1。

✅ 先(int)强制转换再做===比较（PHP 8.0 起字符串与数字比较规则已收紧，但显式转换仍是唯一可靠的写法）。

7. 把类型化属性当成"自动初始化"

❌ 7.4 新增的类型化属性private array $items;未赋值就读取，抛 "must not be accessed before initialization"。

✅ 声明时给默认值：private array $items = [];。

8. 排查时不记录版本与环境

❌ 只看代码，不知道线上到底跑的是 7.4.3 还是 7.4.33，php.ini又是什么。

✅ 在接口响应头或日志里带上PHP_VERSION和关键 ini 值，出问题时一眼可见。

总结

排查 PHP 7.4 老项目的数据异常，方法就一句话：不要看中间变量，要看链路的两个端点——数据库里查出来的原始值，和json_encode()吐出的最终字符串。两端一比对，变形发生在哪一层自然就清楚了。剩下的都是按现象查表，逐个收敛。