从 FilamentPHP 到 Livewire 4：我们为什么要重构整个后台架构
在 Teanary gitee.com/teanary/tea… 项目的发展过程中，我们做出了一个重大技术决策：将后台管理系统从 FilamentPHP 完全重构为原生 Livewire 4 方案。这个决定意味着放弃 Filament 的很多“开箱即用”的便利，而选择自己掌控每一个界面和交互细节。这个选择看起来冒险，但对 Teanary 的长期健康发展来说，是非常值得的。
项目背景概览
Teanary 是一个面向全球市场的电商平台系统，支持：
-
多语言、多货币结算；
-
多节点部署数据同步；
-
灵活的后台商品、订单与用户管理；
-
AI 辅助翻译及自动采集等功能。(Gitee)
最初我们采用了 FilamentPHP 为后台管理提供基础界面和CRUD快速搭建。在开发过程中，我们逐渐感受到 Filament 的局限性，特别是在定制性、性能优化和架构可控性方面，这促使我们做出了重构的决定。
为什么要放弃 FilamentPHP？
FilamentPHP 对低成本快速搭建后台管理界面很有帮助，但它也带来了几个明显的痛点：
1. 定制能力受限
Filament 的 UI 和交互逻辑都有固定结构。对于 Teanary 这样业务逻辑复杂、模块定制化需求高的项目，Filament 既无法灵活应对，又难以调整。长期下来，我们发现自己被 Filament 的抽象层限制住了表达业务需求的自由度。
2. 与最新 Livewire 版本兼容性受限
Filament 深度绑定 Livewire 内部机制，导致在 Livewire 4 出现后，Filament 的适配存在滞后与限制。官方为了让 Filament 支持 Livewire 4，甚至推出了 Filament v5 来做兼容适配这层工作，这说明 Filament 在内部架构上仍然很依赖 Livewire 的具体实现细节。(Laravel News)
这样的依赖让我们无法完全利用 Livewire 4 带来的性能与体验提升。
3. 性能与架构优化需求
随着 Teanary 的业务增长，对后台性能和响应速度提出了更高要求：
-
Filament 在页面切换时需要在后台频繁渲染完整组件结构，造成性能瓶颈；
-
多管理员同时在线操作时，部分 Filament 默认行为存在性能浪费；
-
Filament 的封装层在复杂业务场景下会引入难以察觉的性能负担。
相比之下，Livewire 4 引入了更精细的智能导航、局部渲染和更小的数据传输机制，这些对提升后台操作体验非常关键。(LearnKu)
为什么选择 Livewire 4？
经过调研和试用，我们最终将重心转向了 Livewire 4，并基于此重写后台：
🔹 全自主可控的 UI 体系
我们能够完全掌控后台视图和组件结构，不再受制于 Filament 的抽象和限制。这让我们在：
-
页面架构设计；
-
组件交互逻辑；
-
可访问性与 UI 一致性实现；
这些关键方面拥有了更高的自由度。
🔹 Livewire 4 的架构优势
Livewire 4 带来了智能导航、局部渲染优化和更高的性能效率，使得后台响应更快、更流畅，用户体验显著提升。(LearnKu)
具体来说：
-
页面切换无需刷新整个页面；
-
更小的数据传输量；
-
组件生命周期和渲染更高效；
-
前端开发者体验更好。
这恰恰符合 Teanary 希望实现“像 SPA 一样流畅后台体验”的目标。
🔹 提升代码质量与可维护性
重写后台让我们有机会：
-
重构后台核心逻辑层结构（如业务 Services、Livewire 组件合理划分）；
-
更明确的职责分层；
-
完善测试覆盖，包括 Livewire 组件单元测试和业务逻辑测试。(LearnKu)
这对长期维护、快速迭代具有重要意义。
我们在重构中学到的经验
通过这次迁移，我们总结了几点原则，希望对类似项目有所启发：
✔ 不要被“快速搭建”的工具锁住
短期减少工作量并不等于适合长期架构。技术选型要对长期维护成本负责。
✔ 预估复杂业务的成长路径
当业务复杂度增加到一定程度时，底层框架的抽象可能成为负担，而不是加速器。
✔ 技术选型要兼顾定制性与性能
灵活性高的技术栈更适合对 UI/UX 有高要求、业务变化快的项目。
总结
经过权衡，Teanary 的后台重构是一个经过深思熟虑的决定：
➡️ 从FilamentPHP（适合快速搭建）
➡️ 到Livewire 4 原生架构（适合可控性 & 性能 & 长期维护）
这个改变让我们在项目架构、开发体验和用户体验上都向前迈出一大步。未来随着 Teanary 平台的增长，这样可控、灵活且高性能的后台架构将带来更多可能。
如果你也正在考虑类似的技术栈选型，这篇文章希望能为你提供参考思路。欢迎讨论交流！
