咨询：能否用Laravel逐步重构超大型老旧PHP应用？

绝对可以实现这种渐进式重构的方案，我来帮你拆解可行性和具体落地思路：

一、路由分流：Laravel与旧系统共存完全可行 #

你的思路非常正确——用Laravel承载新开发/已重构的模块，剩余请求转发到老系统，这完全可以通过Laravel的路由机制实现：

1. 优先定义新模块路由：把所有新开发的页面、接口路由放在routes/web.php（或api.php）的最前面，确保它们被优先匹配。
2. 用通配符兜底转发旧请求：在路由文件的最后添加一个fallback路由，匹配所有未被新路由覆盖的请求，直接转发到老系统的脚本。示例代码如下：

// 新模块路由（示例）
Route::get('/new-admin/dashboard', [NewDashboardController::class, 'index']);
Route::resource('/new-products', ProductController::class);

// 兜底转发旧系统请求
Route::fallback(function () {
    $requestUri = request()->path();
    // 这里替换成你的旧系统实际路径
    $oldScriptPath = base_path('../legacy-app/' . $requestUri);
    
    if (file_exists($oldScriptPath)) {
        // 传递当前请求的参数和会话
        $_GET = request()->query()->all();
        $_POST = request()->post();
        // 引入旧脚本，执行后终止Laravel的请求周期
        require $oldScriptPath;
        exit;
    }
    
    abort(404, 'Page not found');
});

关键注意点：

• 会话共享：要确保Laravel和旧系统的用户会话互通。如果旧系统用原生$_SESSION存储会话，你可以修改Laravel的会话驱动为file（和旧系统一致），或者把旧系统的会话迁移到数据库存储，然后在Laravel中读取旧会话的用户标识，同步到Laravel的Auth系统（比如写一个自定义中间件）。
• 请求参数传递：要确保$_GET、$_POST等全局变量和旧系统的预期一致，避免旧脚本因为参数缺失报错。

二、Eloquent适配旧数据库：灵活兼容非标准结构 #

Eloquent完全可以适配老旧的数据库设计，甚至不需要大规模重构数据库，你可以通过模型配置实现兼容：

1. 基础适配非标准表/字段 #

比如旧表的命名、主键、字段名不符合Laravel的约定，你可以在模型里自定义：

class LegacyUser extends Model
{
    // 指定旧表名
    protected $table = 'tbl_users_old';
    // 指定非自增/非int类型的主键
    protected $primaryKey = 'user_code';
    public $incrementing = false;
    // 如果旧表没有created_at/updated_at时间戳字段
    public $timestamps = false;
    // 字段映射（旧表字段名 => 模型属性名）
    protected $fillable = ['user_code', 'usr_name', 'usr_email'];
    protected $attributes = [
        'usr_name' => 'name',
        'usr_email' => 'email',
    ];
}

2. 混合使用原生SQL与Eloquent #

针对你提到的大量直接SQL代码，Laravel完全支持原生查询，你可以逐步迁移：

• 用DB::select()直接执行旧的SQL语句，无需修改：

$oldOrders = DB::select('SELECT * FROM tbl_orders_old WHERE user_code = ? AND order_date > ?', [$userCode, $startDate]);

• 慢慢把常用的查询重构为Eloquent模型或查询构建器，不用一次性完成。

3. 数据库重构的可选方案 #

如果后续想逐步优化数据库结构，可以采用读写分离+双写的方式：

• 新系统先读写旧数据库，同时在新表中同步数据；
• 待新模块稳定后，逐步切换到新数据库，最后淘汰旧表。

三、针对你的补充细节的额外建议 #

1. 无测试的风险应对 #

因为旧系统没有测试，重构时要格外小心：

• 给所有新开发/重构的模块编写PHPUnit测试，确保新功能稳定；
• 可以给旧系统的核心功能编写简单的接口测试（比如用Laravel的HTTP测试），每次重构前跑一遍，避免破坏原有功能。

2. PHP版本兼容与升级 #

当前旧系统运行在PHP 5.6，你可以选择Laravel 5.5（支持PHP 5.6）作为过渡版本，之后逐步升级PHP到7.4（兼容Laravel 8+），再升级Laravel版本。这种渐进式升级的风险远低于一次性替换。

3. 对比之前的Doctrine尝试 #

Eloquent比Doctrine更轻量化、灵活，适合这种渐进式迁移——你可以混合使用原生SQL、查询构建器和ORM模型，不需要强制把所有数据库操作都改成ORM，这能大幅降低迁移的阻力。

这种分模块渐进式重构是大型遗留系统升级的最优方案之一，只要做好路由分流和会话共享，完全可以实现新旧系统平稳过渡，不用担心中途失败的问题。

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