第一章:技术选型与架构设计

大家好,我是你们的前端老司机。今天咱们聊聊项目起步最关键的一步——技术选型和架构设计。

说实话,我见过太多项目死在起跑线上。选了个不趁手的框架,写到一半发现坑太多。或者目录结构一团乱麻,新同事来了三天找不到入口文件。嗯,这些坑我都踩过。

1.1 选框架:React、Vue 还是 Angular?

先别急着站队。框架没有绝对的好坏,只有合不合适。

React:灵活,生态庞大。适合大型项目、复杂交互。我个人习惯用它做中后台系统,因为状态管理方案多,社区资源丰富。

Vue:上手快,模板语法直观。适合中小型项目、快速原型。我在做电商活动页时常用它,开发效率确实高。

Angular:全家桶,强约束。适合企业级应用、团队协作。如果你团队有 Java 背景,Angular 的依赖注入和模块化会让他们感觉很亲切。

我的建议:如果你一个人单干,选你熟悉的。如果是团队项目,看团队技术栈。别为了「时髦」选一个没人会的框架。

小技巧:可以做个简单的 POC(概念验证)。花半天时间用每个框架写一个 Todo List,哪个顺手就用哪个。

1.2 项目目录结构设计

目录结构这事儿,说白了就是「怎么放文件才不乱」。我见过最离谱的项目,所有组件都扔在 components 文件夹里,足足 200 多个文件。找东西全靠 Ctrl+F。

这里分享一个我常用的结构:

src/
├── api/          # 接口请求
├── assets/       # 静态资源(图片、字体)
├── components/   # 公共组件
├── hooks/        # 自定义 Hooks
├── layouts/      # 布局组件
├── pages/        # 页面组件
├── router/       # 路由配置
├── store/        # 状态管理
├── styles/       # 全局样式
├── utils/        # 工具函数
└── App.vue       # 入口文件

为什么要这么分?

  • 按功能模块分:每个文件夹只做一件事。比如 api 只放请求,hooks 只放逻辑复用。
  • 扁平化优先:不要嵌套超过 3 层。我曾经见过 components/common/buttons/primary 这种路径,找文件得点半天。
  • 命名规范:文件夹用小写 + 中划线,组件用大驼峰。比如 user-profile 文件夹里放 UserProfile.vue

注意:别把业务逻辑和 UI 混在一起。比如在 components 里写接口请求,这就是个坏味道。

1.3 组件化设计思想

组件化,说白了就是把页面拆成一个个积木。每个积木只管自己的事,拼起来就是完整的页面。

单一职责原则:一个组件只做一件事。比如「用户头像组件」只负责显示头像,不负责获取用户数据。

可复用性:把公共部分抽出来。比如按钮、输入框、弹窗这些,做成通用组件。我在项目中遇到过,同一个弹窗样式写了 5 遍,后来改成通用组件,省了一半代码量。

可测试性:组件越独立,越容易测试。比如一个纯展示组件,给它传什么 props 就显示什么,测试起来特别简单。

来看个例子:

<!-- 不好的写法:组件里直接发请求 -->
<template>
  <div>
    <span>{{ user.name }}</span>
  </div>
</template>

<script>
export default {
  mounted() {
    axios.get('/api/user').then(res => {
      this.user = res.data
    })
  }
}
</script>

<!-- 好的写法:数据由父组件传入 -->
<template>
  <div>
    <span>{{ name }}</span>
  </div>
</template>

<script>
export default {
  props: {
    name: String
  }
}
</script>

看到了吗?好的组件只关心「怎么展示」,不关心「数据从哪来」。这样你可以在任何地方复用这个组件,只要传个 name 就行。

1.4 状态管理怎么选?

状态管理,就是管理「多个组件共享的数据」。比如用户登录状态、购物车数据。

方案 适用场景 复杂度
Pinia / Vuex Vue 项目,中等以上复杂度 中等
Redux Toolkit React 项目,大型应用 较高
Zustand React 项目,轻量级
Context API React 项目,简单状态

我的经验是:别一上来就用状态管理。很多场景下,props 传递 + 事件通信就够用了。等发现 props 传递太深(超过 3 层),再考虑引入状态管理。

避坑指南:我曾经在一个小项目里用了 Redux,结果写了大量样板代码。后来换成 Zustand,代码量减少 60%。所以,选方案要「按需」,别过度设计。

1.5 路由设计

路由就是页面的「导航地图」。好的路由设计能让项目结构清晰,坏的设计会让你改一个页面要改 3 个文件。

嵌套路由:适合有侧边栏、顶部导航的布局。比如:

/admin
  /admin/users
  /admin/settings
  /admin/reports

动态路由:适合详情页、编辑页。比如:

/article/:id
/user/:userId/profile

路由守卫:控制页面访问权限。比如未登录用户跳转到登录页。

我个人习惯把路由配置单独放一个文件,按模块拆分。比如 router/modules/user.js 放用户相关路由,router/modules/admin.js 放管理后台路由。这样找起来方便,也容易维护。

1.6 总结

技术选型和架构设计,说白了就是「为未来做打算」。选框架时想想团队能力,设计目录时想想扩展性,写组件时想想复用性。

嗯,这一章就到这里。下一章咱们聊聊「项目初始化与开发环境搭建」,到时候我会分享一些我常用的脚手架配置和开发工具。

记住:好的开始是成功的一半。花时间在架构设计上,后面写代码会顺畅很多。


公众号:蓝海资料掘金营,微信deep3321