Laravel数据格式统一问题：蛇形与驼峰命名如何转换？

当前写法是否合适？ #

直接让服务层返回蛇形命名（snake_case）数据，却在另一个使用驼峰命名（camelCase）的服务中调用，这种做法并不合适。核心问题在于命名风格不统一会带来：

• 协作时的认知负担，团队成员需要频繁切换命名习惯
• 代码可读性下降，容易因变量名拼写错误引发逻辑bug
• 后续维护成本升高，修改字段时要兼顾两种命名格式

解决方案 #

方案1：统一服务层返回格式（推荐） #

从根源解决问题的方式是让SupportService的findUserTicket方法直接返回驼峰命名的数据，保持服务层输出格式一致。Laravel提供了便捷的工具来实现这一点：

// SupportService.php
use Illuminate\Support\Str;

public function findUserTicket($userId)
{
    // 假设原查询返回蛇形命名的数组/模型实例
    $ticket = DB::table('support_tickets')
        ->where('user_id', $userId)
        ->first();

    // 转换数组键名为驼峰
    return collect($ticket)->mapWithKeys(function ($value, $key) {
        return [Str::camel($key) => $value];
    })->toArray();
}

如果使用Eloquent模型，也可以通过自定义访问器或者在模型中设置$casts来自动转换字段名，但手动转换数组的方式更轻量可控，不会影响其他依赖该模型的场景。

方案2：在调用方转换格式 #

如果SupportService已经被其他服务依赖，修改返回格式会产生副作用，那么可以在调用它的服务中单独转换命名格式：

// 调用方服务类
use Illuminate\Support\Str;

public function handleUserTicket($userId)
{
    // 获取蛇形命名数据
    $snakeCaseData = app(SupportService::class)->findUserTicket($userId);
    
    // 转换为驼峰命名
    $camelCaseData = collect($snakeCaseData)->mapWithKeys(function ($value, $key) {
        return [Str::camel($key) => $value];
    })->toArray();

    // 后续逻辑使用$camelCaseData
}

方案3：使用DTO标准化数据传输 #

如果追求更规范的代码架构，可以定义数据传输对象（DTO），让SupportService返回DTO实例，调用方直接使用DTO的驼峰属性，彻底隔离底层数据格式：

// SupportTicketDTO.php
class SupportTicketDTO
{
    public function __construct(
        public int $id,
        public int $userId,
        public string $ticketSubject,
        // 根据实际字段添加其他属性
    ) {}

    // 从蛇形数据生成DTO的静态方法
    public static function fromSnakeArray(array $data): self
    {
        return new self(
            id: $data['id'],
            userId: $data['user_id'],
            ticketSubject: $data['ticket_subject'],
            // 对应转换其他字段
        );
    }
}

// SupportService.php
public function findUserTicket($userId): SupportTicketDTO
{
    $snakeData = DB::table('support_tickets')
        ->where('user_id', $userId)
        ->first()->toArray();

    return SupportTicketDTO::fromSnakeArray($snakeData);
}

// 调用方使用示例
$ticketDto = app(SupportService::class)->findUserTicket($userId);
echo $ticketDto->userId; // 直接使用驼峰命名的属性

DTO模式的优势在于类型安全，IDE会自动提示属性名，避免拼写错误，同时让数据结构更清晰，适合中大型项目长期维护。

总结 #

优先推荐方案1，从服务层统一输出格式，这是最简洁且能彻底解决命名混淆的方式；如果服务不能修改，选择方案2做临时转换；追求代码规范和可维护性的话，方案3的DTO模式是长期最优解。

内容的提问来源于stack exchange，提问作者Ruslan