前后端分离的美食推荐商城这两年算是练手项目里出镜率最高的品类之一。我最近把一个完整的 SpringBoot Vue MyBatis MySQL 商城系统从设计到部署重新整理了一遍发现很多细节值得沉淀。这个系统不是一个空壳用户注册登录、美食分类浏览、推荐理由展示、评分排行、购物车、订单流程、评论评价一条完整业务链都串起来了。前端 Vue 做单页面应用后端 SpringBoot 暴露 REST 接口MyBatis 负责 SQL 映射MySQL 存数据。适合什么人看正在做课设或者准备项目经历的同学、刚学完框架想找个完整项目实战的新手、想做技术复盘顺便梳理前后端分离经验的开发者都能从里面找到可以直接落地的细节。下文所有配置、代码结构、排错顺序都是我在真实环境里跑通后记下来的可以直接抄作业也欢迎你在此基础上改自己的业务。1. 项目全景前后端分离美食商城的架构决策1.1 为什么是前后端分离真实项目里的一笔账先说一个最朴素的问题这个商城为什么非要拆成前后端两个工程直接用传统模板引擎在服务端渲染页面不行吗答案是可以但放在今天前后端分离有实打实的优势。我第一次做类似商城的时候用的就是服务端模板引擎后来遇到了几个痛点。第一个痛点是页面交互复杂购物车的即时更新、分类切换的局部刷新、推荐卡片的状态变化这些全靠服务端渲染会非常别扭每点一次按钮都要整页刷新或手动拼接 HTML前端代码又乱又难维护。第二个痛点是前后端并行开发经常被阻塞接口还没写好时前端页面只能等排期被拉得特别长。拆成前后端分离之后前端只关心渲染和交互后端只关心数据和业务。两边把接口约定写好就可以同时动工开发效率是实打实的提升。还有一个隐藏好处是接口复用商城类系统最容易遇到多端需求以后要做小程序端或者 APP 端后端接口能直接复用。我自己就见过一个项目老板临时说要加个校园分销小程序因为原先是前后端分离架构后端基本没怎么动前端新增一套界面就接上了这种场景在单体模板项目里会很痛苦。当然前后端分离不是没有成本。跨域、鉴权、部署复杂度都会相应增加后面几章我会逐个讲这些坑。我的选型逻辑就是综合评估了团队规模、业务复杂度、后续扩展性之后做的决定中小型、业务链路清晰、有多端潜在需求的项目优先拆。1.2 技术选型的四个关键判断技术栈方面我做了四个判断。第一后端用 SpringBoot。相比传统 Spring MVC 加大量 XML 配置SpringBoot 内嵌 Tomcat、自动配置、Starter 机制开发体验好太多。打成一个 jar 包直接 java -jar 就能跑部署链路非常干净非常适合快速落地这种中小型业务系统。第二前端框架选 Vue。Vue 的上手曲线在前端框架里算温和的组件化开发和响应式数据绑定对商城这种交互密集的页面非常合适。生态里 Vue Router 做页面路由、Axios 做 HTTP 请求都是非常成熟的配套。Vue 3 的组合式 API 配合 setup 语法代码组织也更好维护。第三ORM 层选 MyBatis。商城系统经常要处理多表联查、动态条件拼接比如按分类筛选、按价格区间查询、按销量排序MyBatis 的动态 SQL 写起来直观可控。排查慢查询时可以直接把 SQL 拿到数据库客户端里执行验证这种贴近 SQL 的掌控感是 JPA 和 Hibernate 给不了的。技术组件解决的核心问题为什么不用备选方案SpringBoot快速构建后端服务、内嵌容器、自动装配传统 SSM 配置繁琐上手成本高Vue前端组件化、响应式交互相比 React 学习曲线更平缓生态成熟MyBatisSQL 映射、动态 SQL、灵活定制JPA 对复杂 SQL 和多表查询控制力弱MySQL关系型数据存储、事务支持足够稳定部署维护成本低第四数据库用 MySQL。结构化业务数据、事务支持、部署成本都符合项目定位。选型时我还对比过一些现成的快速开发脚手架它们确实把权限、代码生成都做好了但如果目标是想彻底搞懂前后端分离项目从零到一的完整过程自己手搭一遍收获大得多。后面很多细节比如跨域怎么处理、MyBatis 的二级缓存怎么配、Vue 路由 history 模式部署后为什么会 404不亲手踩一遍根本记不住。2. 数据库设计与后端实现SpringBoot MyBatis MySQL 的协同工作2.1 数据库设计七张业务表把美食商城装进去先说数据库。美食推荐商城本质上是零售系统的变体核心绕着商品转。我设计了七张核心表用户表 user、分类表 category、美食表 food、购物车表 cart、订单表 orders、订单明细表 order_item、评价表 comment。为什么不把购物车塞进订单里这是面试也爱问的一个点。购物车是“未确认的临时选择”订单是“已经完成的交易行为”两者生命周期完全不同。状态不同、业务阶段不同的数据不要强行放一张表。user 表字段基本是 id、username、password、nickname、avatar、phone、create_time。密码存储我用了 BCrypt 加密不用明文这个习惯建议从练手项目就开始养成。category 表包含 id、name、parent_id、sort_orderparent_id 是为了将来支持二级分类预留的比如“主食”下面再分“面食”“饭类”。虽然一期没做但结构上留好后面扩展零成本。food 表是核心表字段包括 id、category_id、name、description、image、price、stock、sales_count、rating、recommend_reason、is_recommend、status、create_time。其中 recommend_reason 是美食推荐商城的灵魂字段首页重点推荐位就是靠 is_recommend 加上这个推荐理由文案驱动的。订单相关两张表要重点提一下。orders 主表存 order_no、user_id、total_price、status、create_timeorder_no 用时间戳加随机序列生成保证唯一。order_item 子表存 order_id、food_id、quantity、price下单时把价格快照存一份好处是之后即使 food 表改价或者下架订单明细里依然保留当时的成交价这属于非常基础但重要的快照意识。comment 评价表存 user_id、food_id、content、rating、create_time首页的评分排行直接对 rating 做聚合查询就行。建库时还有两个容易忽略的设置。一个是字符集建库用 utf8mb4 而不是 utf8因为 utf8 在 MySQL 里最多存 3 字节遇到 emoji 或特殊字符会报错或变成问号。排序规则我用的 utf8mb4_general_ci性能和兼容性都够用。价格字段用 decimal(10,2)不要用 float 或 double浮点数做金额计算会丢精度这个在涉及钱的业务里是红线。2.2 后端工程搭建与分层设计后端我建的是 Maven 单模块工程结构上严格分成四层controller、service、mapper、entity。controller 只负责接收参数、返回统一响应体service 写业务逻辑比如下单时校验库存、计算总价、生成订单号mapper 是 MyBatis 的数据访问接口entity 对应数据库表结构。很多初学者喜欢把业务逻辑堆在 controller 里短期看代码少后期维护会很痛苦。这个项目节点少分层的好处可能还不够明显但到订单这种涉及多表写入的接口时你能明显感受到逻辑分层带来的清晰感。哪个环节出了问题直接定位到对应层不用在一坨代码里翻来翻去。统一响应体我也单独封装了一个 Result 类包含 code、message、data 三个字段controller 里所有接口都返回这个结构。前端 axios 拦截器统一判断 code 是否为 200再决定走成功回调还是错误提示。这样后端抛业务异常时前端不用每个接口单独写一遍错误处理。pom.xml 依赖方面核心几个就够了spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-java、lombok。额外加了 spring-boot-starter-validation 做参数校验commons-lang3 做字符串工具。数据库连接池不用额外引入SpringBoot 默认的 HikariCP 已经是非常好的选择。application.yml 配置有几个关键点需要记一下。数据源 url 要加上 useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse这个组合能避开大部分连接乱码和时区报错。MyBatis 要配置 mapper-locations: classpath:mapper/*.xml让 SpringBoot 能正确找到 XML 映射文件。再配一个 map-underscore-to-camel-case: true这样数据库里 create_time 这类下划线字段可以自动映射成实体类的 createTime省掉大量手写 resultMap 的工作。# application.yml 核心配置片段 spring: datasource: url: jdbc:mysql://localhost:3306/food_mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true2.3 MyBatis 的关键细节动态SQL、缓存与TypeHandlerMyBatis 是这四件套里最值得花时间啃细节的部分。先说动态 SQL商城的列表页有各种筛选条件按分类查、按价格区间查、按推荐位查、按评分排序组合起来非常多。我在 FoodMapper.xml 里写了一个用 if 和 where 标签组合的查询where 标签会自动处理掉多余的 AND 或 OR免去手工拼条件串的麻烦。foreach 标签在批量插入订单明细时用到一次 insert 多条 order_item。这两类动态 SQL 是商城后端最高频的操作建议做这个项目的人都亲手写一遍。缓存方面MyBatis 的一级缓存是 SqlSession 级别的默认开启同一个会话里重复查询同一条 SQL 会直接走缓存。二级缓存是 namespace 级别的需要在 Mapper XML 里加一行 cache 标签手动开启。商城场景里美食列表和分类列表这种读多写少的查询开二级缓存收益还不错。但有个大坑如果两张表关联查询数据变更只清空了本 namespace 的缓存另一张表的缓存还是旧的。所以我的做法是简单单表查询的 mapper 才开二级缓存涉及多表关联的保持默认关闭。这是 MyBatis 面试里高频的隐藏考点不影响做项目但面试聊到会很加分。TypeHandler 也单独说一句。比如数据库中 status 字段存的是 int0 表示下架1 表示上架实体类里对应一个状态枚举就可以自定义 TypeHandler 做转换。我在项目里写了一个枚举转换器Java 层用枚举写业务判断可读性比满屏魔法数字强太多。MyBatis 初始化时XmlConfigBuilder 会解析这些映射配置如果 XML 里有错误项目启动阶段就能直接报出来这个特性可以用来做配置自检不用等运行期才发现问题。3. 前端 Vue 实现从页面拆解到数据联调3.1 环境准备与工程初始化前端这块先说环境。Vue 项目需要 Node.js建议装 LTS 版本npm 会随 Node 一起装好。国内环境下建议顺手把 npm registry 切到国内镜像比如淘宝源不然装依赖的时候等待时间很折磨人。然后全局安装 vue/cli用 vue create 命令创建工程。创建过程中有几个交互式选项。我建议勾上 Router 和 Pinia或者 Vuex看版本CSS 预处理器可以选 Sass 或 Less后面写样式会舒服很多。版本选择上如果项目从零开始直接用 Vue 3组合式 API 配合 setup 语法代码组织更清爽。我下面的思路在 Vue 2 和 Vue 3 里基本通用。工程初始化完成后第一件事就是整理目录。我习惯把 src 下的内容按 views、components、router、store、utils、api 划分其中 api 目录专门放接口请求封装每个业务模块一个文件比如 food.js、order.js、user.js。这样做的核心好处是页面组件里基本看不到裸的 axios 调用所有接口地址集中管理。见过不少同学在页面里到处写 this.$http.get接口一变就要全局搜索替换这个习惯真的建议早改。3.2 页面与路由SPA 里的业务流转页面结构我拆成了这几块。首页是核心包含顶部导航、推荐美食轮播、分类导航、推荐理由卡片列表。美食列表页支持分类筛选和排序。美食详情页展示图文介绍、推荐理由、用户评分和评价列表。购物车页做数量增减和金额动态合计。下单页选择地址项目里简化成备注、确认订单。订单列表页按状态分组展示。个人中心页放用户信息和头像。登录和注册做成独立页面用路由切换。路由这块常规页面在 router/index.js 里配置组件路径用 meta 字段控制是否需要登录。我在全局前置守卫 beforeEach 里做了判断未登录访问购物车和订单页时直接重定向到登录页并带上 redirect 参数登录成功后跳回原目标页。这里涉及 Vue Router 中 params 和 query 的选择问题。页面间传参时query 适合携带可分享的参数比如 ?category2刷新页面参数还在URL 里也直观。params 适合传对象或者不想暴露在地址栏的数据但要小心刷新后 params 可能丢失。商城项目里从列表页跳详情页我一般用 query 传 foodId因为详情页需要支持刷新和分享链接刷新后 foodId 还在 URL 上页面就能正常加载数据。3.3 与后端联调axios 封装、跨域与会话保持axios 封装这块我习惯做一个 request.js 统一出口。baseURL 根据环境变量区分开发环境指向本地后端服务生产环境走相对路径。请求拦截器里把 token 从 localStorage 取出来塞进 Authorization 头响应拦截器里统一处理业务码200 时直接返回 data401 时清理登录态并跳转登录页其他错误码统一弹出提示。这样页面里调用接口就非常简洁。登录态我用的是 JWT无状态、跨语言特别适合前后端分离的鉴权场景。登录成功接口返回 token前端手动存到 localStorage每次请求带在请求头里跨域完全无感。如果后端用 Session 存登录状态Cookie 默认不会跨域携带要额外配置 withCredentials 和 Access-Control-Allow-Credentials两头都要对齐麻烦不少。跨域是前后端分离第一个绕不过去的坎。开发环境下Vue CLI 的 devServer 可以配置 proxy 代理前端请求 /api 开头的接口由 webpack-dev-server 转发到后端服务并重写路径去掉 /api 前缀。这样浏览器里看到的请求是同源的不存在跨域问题。生产环境下我用 Nginx 做了同样的转发配置这是最推荐的做法因为代理同时解决了 Cookie、请求头转发的一致性比单纯在后端开 CORS 更安全可控。// vue.config.js 开发环境代理配置 const { defineConfig } require(vue/cli-service) module.exports defineConfig({ devServer: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/api: } } } } })4. 部署上线从本地到服务器的完整链路4.1 MySQL 部署与数据导入部署阶段我从一个干净的服务器环境开始讲。第一步是装 MySQLLinux 下可以用系统包管理器安装也可以用官方仓库的 rpm 包。装完执行 mysql_secure_installation 设置 root 密码。这里特别要注意MySQL 8 初始化后的默认认证插件是 caching_sha2_password老版本客户端和部分图形工具连不上解决办法是新建应用账号时指定 mysql_native_password或者改 root 账号的认证插件。这一步如果跳过后面后端连数据库会报 SSL 连接错误或者认证失败。提示数据库连接串中SSL 和时区参数建议直接拼在 url 里。SSL 关闭能省去证书握手的额外开销时区参数能避免连接报错两个参数一起带上基本能覆盖九成连接问题。建库和导入数据我建议把所有建库语句、建表语句、测试数据写成一个 init.sql。执行方式很简单mysql -u root -p init.sql。测试数据很重要尤其是美食图片地址开发环境可以用相对路径指向前端静态资源生产环境最好换成完整 URL。我在脚本里放了二十来条美食数据和几条推荐配置首页推荐位演示完全够用。字符集在脚本里就固定好 utf8mb4后面应用连接串里带着 characterEncodingutf8两边保持一致才不会出现中文乱码。有个小技巧导入前先执行 SET NAMES utf8mb4能避免终端环境下中文数据被错误转换。4.2 后端打包与运行参数后端 SpringBoot 项目打包很简单Maven 执行 mvn clean package -DskipTests 跳过测试打包完 target 目录下生成一个 jar 包。为什么 SpringBoot 推荐 jar 而不是 war因为内嵌 Tomcat一条 java -jar 命令就能跑不需要单独装 Web 容器部署成本低很多。面试常问的 SpringBoot 内嵌容器和传统外置容器的区别核心就是再也不用手动处理 Web 容器和应用之间的兼容性问题。运行 jar 时我建议把配置外置。工程里的 application.yml 是默认配置服务器部署时在同目录放一个 application-prod.yml覆盖数据源地址、密码、文件存储路径等环境相关参数启动命令用java -jar food-mall.jar --spring.profiles.activeprod为什么这样做因为数据库密码、服务器 IP 这类信息不该写死在构建产物里代码仓库只保留配置模板实际运行环境参数单独管理。项目不大但这个习惯建议从小养成。jar 运行时区问题也可以在启动命令里加上 -Duser.timezoneAsia/Shanghai。后端机器的防火墙和端口也要处理。SpringBoot 默认监听 8080如果云服务器安全组没放行 8080外部访问会一直超时。我自己踩过这个坑部署完满怀信心打开浏览器结果连接被拒绝排查半天发现是安全组只开了 80 和 22。我的部署清单里永远写一句先 curl 127.0.0.1:8080 确认本地服务正常再检查安全组和防火墙先排除程序问题再查网络问题。4.3 前端构建与静态部署前端部署本质上是把源代码编译成浏览器能直接加载的静态文件。执行 npm run buildVue CLI 会在 dist 目录生成 index.html、js、css、图片等产物。生成的 JS 文件名默认带 hash这是为了版本缓存管理每次发布内容变了文件名也会变浏览器不会命中旧缓存。把 dist 目录的内容复制到 Nginx 的 html 目录或者放到 Tomcat 的 webapps 下都能跑起来。区别在于 Nginx 处理静态文件性能好且配置灵活Tomcat 作为 Java 应用服务器前端静态资源一般不塞给它。生产环境更合理的组合是Nginx 管静态资源和转发后端服务单独跑在本地端口各司其职。这里有一个部署层面特别容易忽视的细节前端页面的接口请求地址如果在代码里写死 localhost部署到服务器后localhost 指向的其实是服务器自己。后端恰好也在同一台机器时倒也能通但前端页面和后端不在同一台机器时就必须把 baseURL 改成后端实际地址。更规范的做法是前端只请求相对路径 /api具体环境差异交给 Nginx 的 location 规则去处理前端代码在本地、测试、生产环境完全不用改。4.4 Nginx 反向代理与 try_filesNginx 配置是部署收尾阶段最重要的一环。需求有两层一要把所有 /api 开头的请求转发给后端 SpringBoot 服务二要解决 Vue Router 的 history 模式下刷新非首页路由会 404 的问题。第一步用 location /api 加 proxy_pass 解决。注意 proxy_set_header 要带上 Host 和 X-Real-IP后端日志才能看到真实客户端 IP。第二步是每个部署 Vue 项目的人都会遇到的经典问题解决方案是 location / 里加 try_files服务器发现请求的资源不存在时统一返回 index.html由前端路由接管页面渲染。# nginx 配置片段 server { listen 80; server_name your-domain.com; location /api { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } }这段配置写完记得 nginx -s reload 生效。验证方式很直观浏览器打开首页按 F12 看 Network接口请求都返回 200 说明转发正常如果 Console 里出现 HTML 无法解析或者 MIME 错误多半是 location 顺序写错或者 proxy_pass 结尾路径有问题。我把这段配置注释写得很详细复制过去改一下端口和静态目录路径就能用。5. 实战问题排查与避坑笔记5.1 跨域问题前后端各自该做什么跨域是前后端分离项目里问得最多的问题我总结了一套标准排查顺序。第一先看浏览器 Network 面板确认请求有没有发出去。如果请求根本没发出是前端代理配置不对如果发出去了但被浏览器拦截说明响应头里缺少 Access-Control-Allow-Origin。第二开发环境优先检查 vue.config.js 里 devServer.proxy 的 target 端口和路径重写规则。第三生产环境检查 Nginx 的 location 匹配顺序/api 规则必须写在 location / 前面否则静态资源请求会先吃掉接口请求。特别提醒不要只靠后端加 CrossOrigin 解决所有问题。跨域配置一旦放开意味着任何来源都能调用接口在生产环境是不安全的。我的做法是生产环境用 Nginx 同源代理后端只允许管理后台域名通过开发环境用 devServer 代理。两层都配置但安全边界始终保持清晰。另外如果后端用了 Session 而前端代理没带 Cookie登录状态会反复丢失排查时留意请求头里有没有 Cookie以及后端有没有正确配置允许凭证。5.2 MySQL 连接错误时区、SSL 与驱动版本MySQL 连接报错十有八九是三类原因时区、SSL、驱动版本。时区问题报错信息通常是 The server time zone value CST is unrecognized解决办法就是连接串加 serverTimezoneAsia/Shanghai。SSL 问题表现在日志里一堆 SSL connection error新版驱动默认使用 SSL连接串加 useSSLfalse 可以关闭避免客户端和服务端因为证书问题反复握手。驱动版本问题也很常见。MySQL 8 的驱动类名变成了 com.mysql.cj.jdbc.Driver旧版本用的是 com.mysql.jdbc.Driver如果配置还在用老类名启动时直接 ClassNotFound。这三个坑我基本每次部署都要踩一遍现在写数据源配置都是成套的url 上直接拼上 useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse。还有一个连接被拒绝的报错error 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock。很多人第一反应是密码错了其实这是 MySQL 服务没启动或者 socket 路径不对。Linux 下先 systemctl status mysql 看服务状态再用 mysqladmin ping 检测。这个报错在本地开发机也很常见尤其是装了 MySQL 但没设开机启动的机器第二天打开电脑连数据库就报这个启动服务就好跟密码一点关系都没有。5.3 MyBatis 映射与缓存问题MyBatis 的坑集中在映射和缓存两处。映射问题最普遍的是下划线转驼峰没开。配置 map-underscore-to-camel-case: true 后create_time 能自动映射成 createTime。如果列名有特殊业务含义比如 user_name 想映射成 loginName那还是要用 resultMap 单独指定。另一个隐蔽问题是查询返回的列多了实体类没有对应属性MyBatis 不会报错只是静默忽略反过来如果 SQL 少查了一列实体类属性就是 null。排查的时候我习惯在 SQL 里临时加上所有字段先确认数据能完整映射再逐步精简效率高很多。缓存问题分两类。一级缓存造成的数据不一致大多数情况下 Spring 事务管理能避免但如果你手动开了 SqlSession 就要小心。二级缓存导致的多表脏数据前面已经提过多表关联查询不要开二级缓存单表查询开了也要清楚数据更新的清理机制。还有一个很实用的排查技巧把 MyBatis 的 SQL 日志打开能看到完整的参数和执行语句。配置方式是在 yml 里设置 mybatis.configuration.log-impl: org.apache.ibatis.logging.stdout.StdOutImpl再把日志级别调到 debug。运行时的 SQL 一眼就能看到比自己猜快多了。5.4 部署后的刷新404问题这个问题的现象非常典型前端部署完成后首页访问正常点菜单跳转也正常但只要按 F5 刷新详情页或者订单页浏览器就报 404。根因在于 Vue Router 的 history 模式基于 History API路由切换是前端自己处理的没有向服务器发真实请求但刷新时浏览器会向服务器请求 /food/detail 这个路径服务器上根本没有这个物理路径于是返回 404。解决办法就是前面提过的 try_files $uri $uri/ /index.html让一切不存在的路径都回退到首页。如果项目部署在 Tomcat 的 webapps 下对应的方案是配置 Tomcat 的 RewriteValve但能上 Nginx 就不要折腾 Tomcat 了。另一个选择是 Vue Router 的 hash 模式URL 里多一个 #刷新不会 404但不利于分享和 SEO。美食推荐商城这种内容型系统我建议坚持用 history 模式配好 try_files体验和是美观程度都更好。问题现象核心原因排查与解决顺序接口请求被浏览器拦截跨域响应头缺失先看 Network再查代理配置或 CORS启动报 ClassNotFound 驱动类mysql 驱动版本与配置不匹配换成 com.mysql.cj.jdbc.Driver刷新页面 404history 模式直访路径不存在配置 try_files 回退 index.html数据库连接 socket 报错MySQL 服务未启动systemctl status 确认再排查密码中文乱码字符集不一致建库用 utf8mb4连接串带 characterEncoding最后聊点个人体会。这个项目做完后我最深的感受是前后端分离真正的难点不在写代码而在把开发环境、联调方式、部署链路、异常排查这一整条线全部打通。SpringBoot、Vue、MyBatis、MySQL 单独看都是成熟工具但组合在一起时每一个环节都可能有一个细节让你卡住。上面这些坑我都是实际踩过之后才总结出血泪经验你照着配置模板和排查顺序走能省下大量翻文档的时间。如果你打算部署到云服务器建议把 MySQL、防火墙、Nginx 三步完整过一遍大概率能一次跑通。后面如果有时间我还会把图片存储、消息通知、推荐算法这几个扩展方向单独展开让这个商城系统再往前推一步。