java后端需配置jackson支持下划线转驼峰（如spring.jackson.property-naming-strategy=snake_case），php侧应启用json_unescaped_unicode并统一数据类型，避免空值歧义。
PHP 传给 Java 的 JSON 字段名大小写不一致
Java 后端（尤其 Spring Boot + Jackson）默认按驼峰命名（userName）反序列化，而 PHP 数组键名常为下划线风格（user_name），直接传过去会导致字段为空或 400 错误。
根本不是“Java 不认下划线”，而是 Jackson 默认没开启下划线转驼峰支持。PHP 侧无需改键名，Java 侧加配置即可统一：
- Spring Boot 全局启用：
spring.jackson.property-naming-strategy=SNAKE_CASE（推荐） - 单个 DTO 类加注解：
@JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class) - 若用老版本 Jackson（@JsonNaming(PropertyNamingStrategy.SnakeCaseStrategy.class)
别在 PHP 里用 ucwords(str_replace('_', ' ', $key)) 拼驼峰——易出错、难维护、还可能破坏已有前端契约。
Java 传给 PHP 的 JSON 数字字段被当成字符串
典型现象："id": "12345678901234567890"（带引号）到 PHP 后，json_decode() 解出来是 string，但业务逻辑误当 int 用，后续计算或比较出错。
这不是 PHP 解析错了，而是 Java 端序列化时把大整数当字符串输出了（出于安全考虑）。PHP 侧不能依赖自动类型转换，必须显式处理：
- 对已知是 ID/时间戳等大整数字段，接收后立刻用
filter_var($val, FILTER_VALIDATE_INT)或is_numeric($val) && (int)$val == $val判断是否可安全转 int - 若可能超
PHP_INT_MAX（如 64 位主键），一律保留为string，后续传给 MySQL 或 Redis 时也用 string 类型操作 - 避免用
(int)$val强转——32 位环境或超范围值会静默变负数或 0
PHP 输出 JSON 时中文字段名被转成 \uXXXX
比如 PHP 数组 ['用户名称' => '张三'] 经 json_encode() 后变成 {"\u7528\u6237\u540d\u79f0":"张三"}，Java 端解析时字段名对不上。
问题出在没启用 JSON_UNESCAPED_UNICODE 标志，且字段名本身是中文（非 ASCII 键名）：
- 必须加标志：
json_encode($data, JSON_UNESCAPED_UNICODE) - 确保整个 PHP 脚本文件保存为 UTF-8 无 BOM 编码
- 数据库查出来的字段别名如果含中文（如
SELECT name AS '用户名' FROM user），PHP 获取后仍是字符串键，同样需该标志才不转义
注意：这个标志只影响键名和字符串值里的中文，不影响数字或布尔值的格式。
双方共用字段命名规范但 PHP 生成 JSON 仍不一致
即使约定都用 snake_case，PHP 输出的 JSON 还是和 Java 不一致？大概率是 PHP 数据源本身类型混乱：
- 从数据库查出的字段，MySQL 的
ENUM或SET类型在 PHP 中可能返回int或string，取决于驱动和配置；用mysqli_fetch_assoc()通常得 string，PDO::FETCH_ASSOC可能因PDO::ATTR_STRINGIFY_FETCHES设置不同而异 - 从缓存（Redis）取的数据是 string，
json_decode($redisVal, true)后再拼数组，容易混入 string 类型的数字字段 - 关键动作：输出前用
array_walk_recursive()扫一遍，对已知应为数字的字段（如price,count）做is_numeric($v) ? (float)$v : $v处理，避免"price": "99.9"这种歧义
最易被忽略的是：PHP 对空字符串 ''、null、0 的 JSON 序列化结果完全一样（都是 null 或 0），但 Java 端反序列化时行为可能不同——务必在协议层明确空值语义，不要依赖隐式转换。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
