Laravel 5.5 安装完成后，默认还是围绕单应用目录组织代码。对业务简单的项目来说问题不大，但一旦同时存在后台、前台和公共逻辑，控制器、模型、请求类与中间件都会持续堆在一起，后期维护成本会明显上升。下面就按照可直接落地的步骤，整理一套基于 Laravel 5.5 的模块化开发方式，重点看目录怎么拆、命名空间怎么接入、服务怎么注册，以及路由该如何按模块分离。
为什么要在 Laravel 5.5 中做模块化
Laravel 安装后的默认结构本质上是单模块应用。项目初期这样做启动快、学习成本低，但在实际业务里，前台、后台、公共基础能力往往会同时演进，如果继续全部塞进同一套目录，常见问题会逐步出现：
- 控制器、模型、请求类数量快速增加，目录会越来越臃肿。
- 后台逻辑和前台逻辑混放，职责边界不清晰。
- 公共代码复用时容易出现耦合，后续调整影响面更大。
这类场景下，把代码按照业务边界拆成多个模块，通常更适合长期维护。本文示例采用三个模块：
- Base：公共基础模块
- Backend：后台模块
- Frontend：前台模块
先准备 Laravel 5.5 运行环境与项目
在开始模块化之前，先确保版本基础一致。原文给出的环境要求是：
- PHP >= 7.0.0
- 安装说明：Laravel 5.5 官方文档
如果项目还没创建，可以直接使用 Composer 安装 Laravel 5.5：
composer create-project --prefer-dist laravel/laravel ./这一步完成后，得到的仍然是 Laravel 默认目录结构，接下来再在此基础上增加模块目录。
模块目录应该怎么拆
第一步是在项目根目录下新建 modules 目录。调整后的项目结构大致如下：
app
artisan
bootstrap
composer.json
composer.lock
config
database
modules
package.json
phpunit.xml
public
readme.md
resources
routes
server.php
storage
tests
vendor
webpack.mix.js其中，modules 目录继续按业务职责拆分为三个模块：
modules/
├── Backend
│ ├── Controllers
│ ├── helpers.php
│ ├── Middlewares
│ ├── Models
│ ├── Providers
│ │ ├── BaseServiceProvider.php
│ │ └── RouteServiceProvider.php
│ └── Requests
│ └── helpers.php
├── Base
│ ├── Controllers
│ ├── helpers.php
│ ├── Middlewares
│ ├── Models
│ ├── Providers
│ │ ├── BaseServiceProvider.php
│ │ └── RouteServiceProvider.php
│ └── Requests
└── Frontend
├── Controllers
├── helpers.php
├── Middlewares
├── Models
├── Providers
│ ├── BaseServiceProvider.php
│ └── RouteServiceProvider.php
└── Requests这种拆法的重点不是把所有内容都“重新发明”一遍，而是让每个模块都具备相对完整的 MVC 与服务注册能力。这样做有几个直接好处：
- 模块内部结构统一，团队协作时更容易定位文件。
- 前台、后台、公共逻辑各自归位，阅读与维护成本更低。
- 后续扩展模块时，复制既有结构即可快速落地。
从目录命名上看，这一方案比较接近“按业务域组织代码”，而不是继续围绕全局共享目录不断叠加文件。
Composer 自动加载与命名空间如何配置
模块目录建好以后，Laravel 还不能直接识别这些新命名空间，需要先修改 composer.json 的自动加载配置。
示例配置如下：
{
"name": "laravel/laravel",
...
"autoload": {
"classmap": [
"database/seeds",
"database/factories"
],
"psr-4": {
"App\\": "app/",
"Base\\": "modules/Base/",
"Backend\\": "modules/Backend/",
"Frontend\\": "modules/Frontend/"
},
"files": [
"modules/Base/helpers.php"
]
}
...
}这里有两个核心点：
1. 为每个模块声明 PSR-4 命名空间
Base、Backend、Frontend 分别映射到各自模块目录，这样模块内的控制器、模型、服务提供者才能按命名空间正常加载。
2. 按需加载公共 helpers 文件
示例里把 modules/Base/helpers.php 放进了 autoload.files。这通常适合存放全局通用的辅助函数。考虑到它属于公共基础模块，放在 Base 下也比较合理。
修改完成后，还需要在项目根目录执行自动加载刷新命令：
composer dumpauto原文这里给出的命名空间示例包括：
- 基础模块命名空间为
namespace Base - 基础模块-控制器命名空间
namespace BaseControllers - 基础模块-模型命名空间
namespace BaseModels
实际使用时，建议你重点检查命名空间声明与目录映射是否一一对应。模块化方案能否稳定运行，最容易出问题的地方通常就是自动加载与命名空间不一致。
服务提供者和路由文件怎么接入
完成自动加载后，还需要把各模块的服务提供者注册到 Laravel 配置里，否则模块能力仍然不会真正参与应用启动。
先修改 config/app.php：
<?php
return [
//省略之前内容
'providers' => [
//...
// 模块化的Provider
BaseProvidersBaseServiceProvider::class, //公共基本服务Provider
BackendProvidersBaseServiceProvider::class, //后台服务Provider
FrontendProvidersBaseServiceProvider::class, //前台基本服务Provider
],
//省略之后内容
];这一步的作用很直接：让 Base、Backend、Frontend 三个模块各自的服务注册逻辑在应用启动阶段生效。通常这里会承接模块内的路由注册、绑定服务、加载配置等工作。
接着，再为各模块建立独立路由文件：
- base.php
- backend.php
- frontend.php路由目录结构可以整理为：
routes/
├── api.php
├── backend.php
├── base.php
├── channels.php
├── console.php
├── frontend.php
└── web.php把路由从单一 web.php 拆开之后，模块边界会更清楚：
backend.php负责后台访问入口与后台页面逻辑。frontend.php负责前台站点相关路由。base.php可以承载公共模块中需要统一接入的路由。
如果你的项目后续还会继续扩展业务域，这种做法比把所有路由都堆在一个文件里更容易管理，也更利于多人协作时减少冲突。
这套 Laravel 5.5 模块化方案适合什么场景
整体看下来，这套做法并不复杂，核心就是四步：
- 在 Laravel 5.5 默认结构上增加
modules目录。 - 按
Base、Backend、Frontend划分模块结构。 - 通过
composer.json配置 PSR-4 自动加载，并执行composer dumpauto。 - 在
config/app.php注册模块服务提供者，再拆分对应路由文件。
如果你的项目已经明显区分前台、后台和公共能力，这种模块化方式会比默认单体目录更易维护。它不依赖过度复杂的扩展包，基本沿用 Laravel 5.5 自身的加载与服务机制，适合作为中小型项目从单体结构走向清晰分层的一种实用方案。
