应直接测试封装逻辑而非json_decode本身，覆盖空字符串、bom、乱码等边界；用assertequals比较解码后php结构，确保文件utf-8无bom，通过依赖注入或mock模拟解析失败，验证错误处理与多版本标志兼容性。
怎么用 PHPUnit 测试一个解析 JSON 的 PHP 函数
直接测 json_decode() 返回值是否符合预期，而不是测 PHP 自带函数本身。重点是你自己写的封装逻辑——比如默认返回空数组、过滤非法字符、兼容非 UTF-8 编码等。
常见错误现象：json_decode() 返回 null 但没检查 json_last_error()，导致测试用例通过了，实际运行却静默失败。
- 写测试前先确认被测函数是否做了错误处理（比如抛异常 or 返回 false）
- 用
json_encode()构造合法/非法输入，别手写 JSON 字符串——容易漏转义 - 测试必须覆盖：空字符串、
null、含 BOM 的 UTF-8、中文乱码字节流、超长嵌套对象
为什么 assertJsonStringEqualsJsonString 不够用
这个断言只比对 JSON 字符串结构等价性，不反映你的真实业务逻辑。比如你的函数把 "123" 转成整数 123，它会认为和原始字符串不相等，但这是你设计的转换行为。
更可靠的做法是：先用 json_decode($input, true) 解析，再用 assertEquals() 比较 PHP 数组结构。
立即学习“PHP免费学习笔记（深入）”；
- 避免用
assertJsonStringEqualsJsonString()测自定义转换逻辑 - 如果函数返回对象（
json_decode($s, false)），就用assertEquals()比较stdClass属性 - 注意浮点数精度：JSON 中
1.0和1在 PHP 数组里都是int，但严格比较可能失败
测试含中文或特殊字符的 JSON 输入时要注意什么
PHP 的 json_decode() 要求输入是 UTF-8 编码，否则直接返回 null。很多测试用例在 IDE 里编辑时默认保存为 GBK 或 UTF-8 with BOM，本地跑得通，CI 上就挂。
- 测试文件本身必须存为 UTF-8 without BOM（VS Code / PHPStorm 右下角可查）
- 不要用
file_get_contents()读取含中文的 fixture 文件后直接传给被测函数——先mb_convert_encoding($s, 'UTF-8', 'auto') - 用
json_last_error_msg()断言错误信息，比只断言null更能定位问题根源
如何模拟 json_decode 失败的边界场景
不能只靠构造非法 JSON 字符串来触发失败，因为有些非法输入（如超深嵌套）在不同 PHP 版本中表现不一致，甚至被 silently 截断。
推荐做法：用 ReflectionClass 临时替换 json_decode 行为，或者直接在被测函数里允许传入 mock 解析器（依赖注入）。
- 简单方案：在函数签名加一个可选参数
$decoder = null，测试时传入function() { return null; } - 复杂但干净：把 JSON 解析抽成独立 service 类，用 PHPUnit 的
createMock()替换 - 别用
override_function()或runkit—— Xdebug 关闭时不可用，且与 PHP 8+ 兼容性差
最常被忽略的是：没测 json_decode($s, true, 512, JSON_INVALID_UTF8_IGNORE) 这类标志位组合在不同 PHP 小版本间的差异。特别是 JSON_INVALID_UTF8_IGNORE 在 7.2+ 才可用，而 CI 环境可能混着多个版本。
