项目上线第三个月，经有加运营那边突然递过来一张需求单——要加一个“推广后台”。前后我盯着屏幕上的台再路由表，差点把咖啡喷上去。后台laravel项目明明已经按admin和api拆好前后台了，经有加用户端、前后管理端、台再移动端接口都跑得挺顺，后台怎么又要后台？经有加

点开需求单细看，原来是前后要给市场部单独开个入口，让他们自己配置banner、台再管理优惠券、后台看投放数据。经有加行政那边听说有后台，前后也跑来问能不能加个“内容审核后台”，台再客服组更绝，直接要一个“工单处理后台”。好家伙，一个系统硬生生要裂成五个后台。

刚开始我想着简单，复制admin模块改改路由不就完了？真动手才发现坑比想象中大。第一个问题就是权限——laravel自带的gate和policy是按角色分的，可这几个新后台的权限跟原admin高度重叠，比如内容审核要能看用户列表，但用户管理后台又不想让审核员碰。强行加角色的话，一个用户得挂七八个角色，光是中间表关联就能把数据库撑胖。

第二个麻烦是路由冲突。原admin用的是`/admin`前缀，新后台想用`/audit`、`/promotion`，但里面很多控制器方法跟原admin重名。比如`DashboardController@index`，三个后台都想用，复制代码倒是快，可以后改一个逻辑得同步改三处，维护成本直接翻倍。

后来我做了个决定——不复制模块，而是把公共逻辑抽成服务层，后台只做薄控制器。具体操作是：新建一个`App\Services\AdminCore`，把用户查询、文件上传、操作日志这些通用功能全塞进去，再让每个后台的路由通过中间件动态绑定不同的权限配置。这么一搞，代码量没增加多少，反而把原来admin里那些臃肿的控制器瘦身了一圈。

但这里有个细节得注意——菜单和面包屑。不同后台的侧边栏菜单长得不一样，可很多操作又共用同一套视图。我干脆把菜单配置扔进数据库，用`menu_key`字段区分当前后台类型，视图里根据这个key动态渲染。刚开始觉得麻烦，后来市场部要求改菜单名字，我直接改数据库一行记录就完事，运营那边都愣住了。

最头疼的是数据隔离。推广后台要看的订单数据跟客服后台看的工单数据本来互不相干，但用户表是共用的。有一次市场部的人手滑，把一个测试用户的手机号改了，结果客服那边查工单时发现用户信息对不上，差点闹出投诉。后来我强制规定：所有跨后台的写操作必须走统一的服务方法，并且加字段标记来源后台，这才把问题按住。

说实话，这种“加后台”的需求以后肯定还会来。与其每次都想着新建模块，不如一开始就把laravel的`app/Http/Controllers`按业务域拆成子目录，再用`Route::group`加不同的命名空间和中间件。你要是问我值不值，我的看法是——如果只是加一个后台，复制粘贴勉强能忍；但当你发现“再加一个”变成常态，就必须停下来把架构捋顺了。毕竟后台这东西，加一个不难，难的是加完以后系统还能不能跑得轻松。