Laravel版本化实现：核心目录下V1子文件夹创建位置咨询

核心原则 #

版本化的核心是隔离不同版本的业务逻辑与数据交互层，尽量让公共代码留在根目录，版本专属的代码放在对应Vx子目录下。

各目录具体方案 #

控制器（Controllers） #

你提到的Controllers/Api/V1结构完全可行，这是行业内API版本化的通用实践。示例结构：

app/Http/Controllers/
├── Api/
│   ├── V1/
│   │   ├── UserController.php
│   │   ├── PostController.php
│   │   └── ...
│   └── V2/
│       └── ...
└── Web/  # 非API控制器保持原有结构即可

路由配置对应命名空间：

Route::prefix('api/v1')
    ->namespace('App\Http\Controllers\Api\V1')
    ->group(function () {
        Route::get('/users', 'UserController@index');
        // 其他V1路由定义
    });

请求验证（Requests） #

和控制器结构对齐，版本专属的验证规则放在Http/Requests/Api/V1下，公共验证逻辑可以留在根目录Requests下复用。示例：

app/Http/Requests/
├── Api/
│   ├── V1/
│   │   ├── StoreUserRequest.php
│   │   └── UpdatePostRequest.php
│   └── V2/
│       └── ...
└── CommonRequest.php  # 多版本通用的验证逻辑

资源转换器（Resources） #

资源类直接决定API的输出格式，和版本强绑定，必须按版本隔离，结构为Http/Resources/Api/V1：

app/Http/Resources/
├── Api/
│   ├── V1/
│   │   ├── UserResource.php
│   │   ├── PostCollection.php
│   │   └── ...
│   └── V2/
│       └── ...
└── ...

比如V1返回id和name字段，V2新增email和created_at，通过不同版本的资源类实现即可。

模型（Models） #

模型是数据层核心，不建议给模型加版本子目录——除非不同版本对应完全不同的数据库表结构（这种场景极少）。正常做法是模型留在根目录app/Models下，不同版本的控制器通过模型的方法、作用域或特征（Traits）适配业务逻辑：

app/Models/
├── User.php
└── Traits/
    ├── V1/
    │   └── UserTrait.php
    └── V2/
        └── UserTrait.php

在对应版本的控制器中，调用模型绑定的版本专属特征方法即可。

服务类（Services） #

服务类封装业务逻辑，分两种情况处理：

• 版本专属的业务逻辑：放在Services/Api/V1下

app/Services/
├── Api/
│   ├── V1/
│   │   ├── UserService.php
│   │   └── PostService.php
│   └── V2/
│       └── ...
└── CommonService.php  # 多版本复用的公共业务逻辑

• 多版本复用的服务：留在根目录Services下，版本专属服务可继承公共服务并修改逻辑。

额外建议 #

• 目录命名统一用V1、V2而非小写v1、v2；
• 路由优先用api/v1前缀，便于后续版本迭代和路由分组管理；
• 公共中间件、异常处理、工具类等无需版本化，保留在根目录即可。

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