从 Nuxt 到 Laravel：博客重构记录

最近为了系统性学习 Laravel，我对原有的博客做了一次重构（虽然其实也没几篇正经文章）。目前还有不少功能尚未完成，但整体已经达到了一个「可以正常使用」的状态。

过去我很少接触像 Laravel 或 Rails 这样 batteries-included 的框架，因此一直不觉得在全栈开发中手动组合各种库有什么问题：需要 ORM 就引入 Prisma 或 Drizzle，需要队列就接入 BullMQ，需要认证就使用 Better Auth。

这些工具本身都很优秀，也完全能够满足业务需求。对于经验丰富的后端开发者来说，这种“按需组合”的灵活性甚至是一种优势。但对于像我这样从前端转向后端的开发者而言，这种灵活反而带来了额外负担——你不仅要解决问题，还要先决定“用什么解决问题”。

在实际使用过程中，我逐渐意识到一种被忽略的成本：选择本身的成本。尤其是在每天刷 X 的时候，各种新工具层出不穷，很容易陷入反复比较与犹豫之中。

我并不是一个热衷追逐技术潮流的开发者。相比不断尝试新工具，我更倾向于选择那些能够长期稳定演进、可以持续积累的技术栈，而不是频繁推翻重来的方案。也正因如此，在这次探索中，我逐渐发现，相比偏“组合式”的前端全栈方案，我反而更喜欢 Laravel 这一类一体化框架。

（题外话：其实在对比过程中，我发现 Rails 的理念更对我的胃口。不过考虑到工作环境，现阶段还是优先深入 Laravel，至于 Ruby 和 Rails，打算放在之后系统补齐。）

回到这次重构本身。重构之前，我的博客采用的是一套典型的全 JavaScript 技术栈：

在重构过程中，我先后尝试了三种不同的实现方案。

第一种是 Laravel + Livewire 的纯 PHP 方案。作为官方推荐方案之一，Livewire 最大的特点是可以用更少的 JavaScript 实现现代前端交互，其语法也与 Vue 有一定相似性，上手成本不高。同时，基于 MVC 的开发模式也让人可以专注于业务本身，而不需要额外设计 API 或处理复杂的前后端边界。

但对于前端出身的开发者来说，相比 PHP，我对 JavaScript 仍然更为熟悉；再加上在了解 Inertia.js 之后，这一方案最终被放弃。

第二种方案是 Laravel + Inertia.js。它同样基于 MVC，但允许继续使用熟悉的前端框架（如 Vue 或 React）以及对应的 UI 生态，同时又避免了传统前后端分离带来的复杂度——不需要单独维护前端路由，也不需要额外设计状态管理。

对于熟悉 Vue / React 的个人开发者来说，我认为这是一个非常平衡且高效的方案。实际上，我也基于 Inertia.js + Vue3 完整实现了博客的后台系统和前台页面。

第三种方案是 TanStack Start。在最终版本中，我将前台页面单独拆分出来，并用 TanStack Start 重新实现了一遍。这么做并不是因为之前的方案无法满足需求，而是出于两个原因：一是练习 Laravel API 的设计，二是体验一下当前比较热门的前端方案。

最终，博客的整体架构变成了：

部署方面基本采用各自框架的推荐方式：

虽然目前功能还比较简陋，但这次重构算是告一段落了。接下来的一些计划包括：

另外相比纠结技术栈，还是多记录些文字更好呢　笑 ٩( ᐛ )و

相关文章