做三款全栈项目后，我重新理解了前端开发

在大学的这两年里，我做了三个全栈项目：一个是为农业企业定制的后台管理系统，两个是我主导构建的 Atom 系列互联网产品。这三段经历，把我从一个“会写功能”的开发者，逐步带向了“能做架构、懂性能、讲工程”的方向。今天这篇文章，我想系统性地梳理一下我在这三款项目中积累的经验，也许可以为和我一样走在全栈路上的朋友，提供一些灵感。

我会从三个关键词出发：架构设计、工程化实践、性能优化。

1. 架构设计：从“堆功能”到“搭体系”的转变

最开始接触项目时，我其实只是把需求翻译成功能，前端写页面，后端写接口。但做嘉农后台系统的时候，我开始真正关注“结构”：比如我发现多个页面都要用表格和弹窗，于是我开始抽象出复用组件，用组合式 API 解耦逻辑和视图；我开始尝试把 Vue Router、Pinia 状态管理、权限控制封装在统一框架里，让新增模块变得简单。

在 Atom 系列项目中，我第一次接触 Monorepo 架构 —— 前端、后端、通用库、部署脚本都放在同一个代码仓库中，用 pnpm workspace 管理依赖，用统一规范保障协同。这种结构，让我逐步意识到：架构的目标是让变化成本变低，是让协作更顺滑。

更重要的是，每一个模块（比如视频系统、推荐系统、互动系统）我都尽量做到职责单一、依赖明确、接口稳定。这让我在后续扩展播放列表、创作者中心的时候变得特别安心。我第一次真切感受到什么叫“好架构让你不惧变化”。

2. 工程化实践：效率是团队协作的天花板

一开始做项目的时候，其实我对“工程化”没什么概念。后来随着项目复杂度变高、参与的人变多，我慢慢感受到：写得快不如协作稳。

从嘉农后台开始，我就引入了 Vite 来提速开发体验，配合 ESLint + Prettier + Git Hooks 去统一代码规范，避免多人协作时的“风格大战”。同时我会在本地搭建 Mock Server，让前后端可以并行推进。

到了 Atom Video，我尝试了更系统的工程规范：比如全局环境变量管理、PR 检查流程、部署前自动打包和测试校验。甚至包括 commit message 的格式都做了限制，CI 流程能自动识别构建类型。

我意识到，工程化不是为了“形式感”，而是让你能安心做事，把心思放在业务逻辑上，而不是修 bug、扯皮或收拾烂摊子上。

3.性能优化实践：以指标为导向，构建高性能前端体验

在多个项目中，我始终将性能优化作为设计与开发的前置目标，遵循“可度量、可感知、可持续”的三大原则，围绕**首屏渲染时间（FCP）、最大内容绘制（LCP）、交互延迟（FID）**等核心指标进行优化。

在 Atom Video 中，我基于 Vue3 + Vite + UnoCSS 构建前端架构，通过按需加载、模块懒加载、路由懒加载等策略，配合 Vite 动态导入机制与缓存优化，有效压缩首屏加载资源至 30% 以下。利用 vite-plugin-visualizer 分析 chunk 体积，配合 HTTP 缓存策略与 gzip 压缩，提升整体加载性能。

此外，我在组件开发中高度关注渲染性能：封面与预览图采用延迟加载（lazy loading），卡片组件中的视频播放器采用 IntersectionObserver 动态挂载，避免因资源预加载影响主线程。对表格数据渲染场景，普遍采用分页加载 + 虚拟滚动策略，有效缓解长列表带来的 DOM 冲击。

Atom Nexus 项目中，我探索了服务端缓存与前端缓存协同策略，针对认证后页面接入本地缓存和 Session 缓存的双缓存模型，减少网络请求次数并优化切换速度。

同时，我在 Lighthouse + WebPageTest 上做过系统分析评估，掌握了 Performance、Network、Timing 多维度调试方式，也能基于用户视角关注核心指标波动，理解优化优先级排序。

总结下来，我并不只是做了性能优化，而是围绕 Web Vitals 指标建立了一套适用于中大型项目的前端性能优化体系。

最后的思考：技术成长不止是技术本身

做完这三个项目后，我有个很深的感受：项目不只是代码的堆砌，它是你能力的外化，是你成长的镜像。

我从刚开始会写页面、调接口的小白，成长为现在可以思考模块划分、选型权衡、工程落地和用户体验的全栈开发者。更重要的是，我学会了反思：哪些设计是为了长远可维护？哪些实现是为了当前性能瓶颈？哪些流程能提升团队效率？

未来我还想在前端架构设计、跨端开发（Web + App + 小程序）、复杂系统性能优化等方向继续深耕。也希望能参与更多优秀的开源项目，在实战中不断成长。