PHP中json_encode()输出1/0而非true/false的根本原因是输入值在编码前已被转为整型或字符串，而非布尔类型；常见于filter_var()默认返回1/0、字符串强制转换或数据库TINYINT字段未手动映射等场景。
PHP json_encode() 输出 true/false 为什么有时变成 1/
根本原因：PHP 的布尔值在 JSON 编码时本该输出 true/false，但如果你看到的是 1 或空字符串，说明数据在进 json_encode() 之前已经不是布尔类型了——大概率是被强制转成了整型或字符串。
常见诱因：filter_var($input, FILTER_VALIDATE_BOOLEAN) 默认返回 1/0（不是布尔），而很多人误以为它返回 true/false；或者用 (int)$bool、strval($bool) 提前污染了类型。
- 检查原始变量类型：
var_dump($your_var)，确认是bool(true)而非int(1) - 用
filter_var($input, FILTER_VALIDATE_BOOLEAN, FILTER_NULL_ON_FAILURE)可返回原生布尔值（失败时返回null） - 避免隐式转换：不要对布尔值做算术运算（如
$b + 0）或拼接字符串（如"$b"）
PHP 里哪些情况会让 json_encode() 拒绝输出标准布尔字面量？
不是 json_encode() 拒绝，而是它只忠实地编码当前 PHP 值的类型。只要传进去的是布尔值，它一定输出 true 或 false。问题永远出在“传进去之前”。
典型翻车现场：
立即学习“PHP免费学习笔记（深入）”；
Wjs Localizing Video
下载
用于端到端视频本地化流程的轻量编排器，路由至四个专注子技能——/wjs-transcribing-audio、/wjs-translating-subtitles...
-
$_GET['flag'] ?? '0'—— 即使 URL 里写?flag=true，$_GET里仍是字符串"true"，不是布尔 -
empty($x) ? false : true看似返回布尔，但如果$x是字符串"0"，empty()返回true，结果反而是false，逻辑没错，但类型没问题——重点还是别依赖字符串输入直接当布尔用 - 数据库字段类型为
TINYINT(1)，PDO 默认取出来是整数1/0，需手动映射：$row['active'] ? true : false
如何安全地把字符串 "true"/"false" 转成 JSON 可识别的布尔值？
别用 filter_var($s, FILTER_VALIDATE_BOOLEAN) 默认行为（它把 "true"、"on"、"1" 都转成 true，太宽泛）。要严格匹配字符串字面量，自己写判断更可控。
- 推荐写法：
$val === 'true' ? true : ($val === 'false' ? false : null) - 如果来源可信（比如配置文件或内部 API），可加一层断言：
assert(in_array($val, ['true', 'false'], true)) - 避免用
json_decode($val, true)反解——这会把"true"当 JSON 字符串解出来，不是你想要的布尔
示例：
$input = $_GET['debug'] ?? 'false';
$debug = $input === 'true' ? true : ($input === 'false' ? false : false); // 默认 fallback
echo json_encode(['debug' => $debug]); // 输出 {"debug":true} 或 {"debug":false}
中文环境下的布尔值传输容易忽略的兼容性点
前端 JavaScript 解析 JSON 时完全不认中文 "真"/"假"，也不认 PHP 的 1/0（除非手动转）。所以后端输出必须是标准 JSON 布尔字面量。
- 确保 HTTP 响应头是
Content-Type: application/json; charset=utf-8，否则某些老浏览器可能误判编码，导致解析失败（虽然不影响布尔，但会影响整个 JSON） - 不要在 JSON 外层再套 HTML 或其他文本——比如
echo "<script>data = ".json_encode($arr).";</script>，这种混排容易被 XSS 过滤器误杀布尔字面量 - 如果用 Swoole 或协程框架，注意
json_encode()不是线程安全的极端场景（极少见），但若开启JSON_INVALID_UTF8_SUBSTITUTE，遇到非法 UTF-8 字节时可能静默替换，间接影响布尔字段所在对象的结构完整性
真正卡住人的，往往不是 json_encode() 本身，而是从请求参数、数据库、缓存里捞出来的那个“看起来像布尔”的值，其实早就不纯了。
