企业官网建设流程全解析

最近整理完一个读书分享评论平台，后端用的 Python + Flask，前端用的 Vue 3。这个项目从我自己的角度来说，算是把“内容分享 + 互动评论”这类社交产品的核心链路完整走了一遍：用户注册登录、发布书评、点赞、回复评论、按书籍聚合内容。整个过程踩了不少坑，也有很多值得记录的经验，这里把整个项目的设计思路、核心代码、联调部署和问题排查完整分享一下。

适合看这篇文章的人有两类：一类是正在准备毕业设计或者找工作的作品集，需要一套拿得出手的全栈项目；另一类是刚学完 Flask 或者 Vue 基础，想做点真实业务练手，又不想把时间浪费在不停试错上的朋友。这套技术栈的特点是清晰、可控、社区资料多，用来做书评这种 CURD 密集型业务非常合适。

1. 项目整体设计与技术选型

1.1 这个项目的核心需求是什么

做项目之前得先想清楚，所谓“读书分享评论”到底要解决什么真实问题。从用户角度来看，核心场景是：我读完一本书，想记录一下自己的感受，也想看看别人对同一本书的评价。从平台角度来看，需要承载的核心功能有四个：书籍信息管理、书评发布与展示、评论互动（点赞和回复）、用户账号体系。

这些需求拆开之后并不复杂，但难点在于它们之间的关联关系。一本书对应多条书评，一条书评下面有多条评论，一条评论还可能回复另一条评论。这种树状和一对多的关系，正是后端数据库设计、前端组件拆分的核心主线。

我的做法是先把这个关系图画清楚：User（用户）一对多 Review（书评），Book（书籍）一对多 Review，Review 一对多 Comment（评论），关键字段是 parent_id 用于评论的嵌套回复。整张业务表其实就四张，但把关系理清楚之后，前后端的接口设计、数据处理逻辑都有了依据。

1.2 技术选型的对比与取舍

这里我重点说一下为什么是 Flask 而不是 Django。Django 确实自带 Admin 后台和完整的 ORM，做 CURD 类项目开发速度很快，但对这个项目场景来说，Flask 有更舒服的地方：第一，Flask 轻量，路由和请求处理逻辑非常直观，学习成本低；第二，前后端分离架构下，后端只需要提供 JSON API，Django 自带的模板、表单等能力基本用不上，反而增加理解负担；第三，Flask 的扩展机制很成熟，SQLAlchemy 管数据库、JWT 做认证、Flask-CORS 解决跨域，按需加载，项目结构干净。

前端选择 Vue 3 + Vite，理由也很直接。Vue 的响应式数据和单文件组件（SFC）形式非常适合这种内容展示型项目，props 往下传书评数据、emit 往上报点赞事件，数据流非常清晰。Vite 作为构建工具，开发环境热更新速度比 Vue CLI（基于 Webpack）快非常多，实测大项目里改一个组件基本秒级刷新。

有朋友会问，那为什么不直接用 Node 全栈，或者前后端都用 Python？这个问题我项目里实际验证过：Flask 负责数据接口，Vue 负责界面交互，职责清晰，部署也简单——后端用 gunicorn 起服务，前端打包成静态文件交给 Nginx 托管，两者各干各的，排错定位非常方便。

1.3 项目目录结构与规划思路

项目采用前后端分离的单仓库结构，根目录下分 backend 和 frontend 两个子目录，各自独立维护依赖：

book-review-platform/ ├── backend/ │ ├── app.py # Flask 入口与蓝图注册 │ ├── models.py # SQLAlchemy 数据模型 │ ├── auth.py # JWT 认证相关 │ ├── api/ │ │ ├── books.py # 书籍接口 │ │ ├── reviews.py # 书评接口 │ │ └── comments.py # 评论接口 │ └── requirements.txt ├── frontend/ │ ├── src/ │ │ ├── api/ # axios 请求封装 │ │ ├── components/ # 通用组件 │ │ ├── views/ # 页面级组件 │ │ ├── router/ # 路由配置 │ │ └── store/ # Pinia 状态管理 │ └── package.json └── README.md

前端把页面级组件和通用组件分开：views 里放 BookList（书籍列表页）、BookDetail（书籍详情页）、LoginView（登录注册页），components 里放 BookCard（书籍卡片）、ReviewItem（书评条目）、CommentTree（评论树）这类可复用单元。这样拆分的好处是，任何一个页面需要复用书评展示，直接引 ReviewItem 就行，不用重复写模板。

后端把接口按业务模块拆成蓝图（Blueprint），books、reviews、comments 各自独立，所有接口统一挂在 /api 前缀下。后端不关心前端怎么渲染，只负责把结构化的 JSON 数据吐出去。这套设计对后期扩展也很友好，比如将来想加一个“我的收藏”功能，只需要新开一个收藏蓝图，不动现有代码。

2. 后端设计：Flask API 与书评业务核心

2.1 数据库模型设计：四张表搞定核心业务

数据模型是整个项目的根基，我花了不少时间在这里。先看 models.py 的核心部分：

from datetime import datetime from werkzeug.security import generate_password_hash, check_password_hash from flask_sqlalchemy import SQLAlchemy from flask_jwt_extended import create_access_token db = SQLAlchemy() class User(db.Model): __tablename__ = 'users' id = db.Column(db.Integer, primary_key=True) username = db.Column(db.String(80), unique=True, nullable=False, index=True) password_hash = db.Column(db.String(256), nullable=False) avatar = db.Column(db.String(256), default='') created_at = db.Column(db.DateTime, default=datetime.utcnow) def set_password(self, password): self.password_hash = generate_password_hash(password) def check_password(self, password): return check_password_hash(self.password_hash, password) def to_dict(self): return { 'id': self.id, 'username': self.username, 'avatar': self.avatar, 'created_at': self.created_at.strftime('%Y-%m-%d %H:%M:%S') } class Book(db.Model): __tablename__ = 'books' id = db.Column(db.Integer, primary_key=True) title = db.Column(db.String(200), nullable=False, index=True) author = db.Column(db.String(100), nullable=False) cover = db.Column(db.String(256), default='') summary = db.Column(db.Text, default='') created_by = db.Column(db.Integer, db.ForeignKey('users.id')) created_at = db.Column(db.DateTime, default=datetime.utcnow) class Review(db.Model): __tablename__ = 'reviews' id = db.Column(db.Integer, primary_key=True) book_id = db.Column(db.Integer, db.ForeignKey('books.id'), index=True) user_id = db.Column(db.Integer, db.ForeignKey('users.id'), index=True) rating = db.Column(db.Integer, default=5) # 1-5 分 content = db.Column(db.Text, nullable=False) likes_count = db.Column(db.Integer, default=0) created_at = db.Column(db.DateTime, default=datetime.utcnow) book = db.relationship('Book', backref='reviews') user = db.relationship('User', backref='reviews') class Comment(db.Model): __tablename__ = 'comments' id = db.Column(db.Integer, primary_key=True) review_id = db.Column(db.Integer, db.ForeignKey('reviews.id'), index=True) user_id = db.Column(db.Integer, db.ForeignKey('users.id')) parent_id = db.Column(db.Integer, db.ForeignKey('comments.id'), default=None) content = db.Column(db.Text, nullable=False) created_at = db.Column(db.DateTime, default=datetime.utcnow)

设计这张表的时候有几个细节值得说。第一，User 表里存的不是明文密码，而是 password_hash，用 werkzeug 自带的 hash 算法加密，这是安全底线，我在项目里坚决不做明文存储。第二，Review 里加了 rating 评分字段，从 1 到 5，这个设计让书评除了文字内容还能聚合出书籍的平均评分，首页可以做“高分好书”推荐。第三，Comment 的 parent_id 指向自身主键，实现多级回复逻辑。如果你只想做一层评论，用 review_id 关联就够了，但考虑到回复场景，这个 parent_id 字段后面会让前端渲染评论树方便很多。

2.2 认证方案：JWT 无状态登录实战

用户要发布书评、点赞、评论，这些敏感操作需要验证身份。我选了 JWT（JSON Web Token）方案，它在前后端分离项目里是最常见的做法。登录成功之后，后端签发一个包含用户 ID 的 token，前端存在 localStorage，每次请求带着走，后端只需要校验 token 是否有效，不需要在服务端保存 session。

from flask import Blueprint, request from flask_jwt_extended import jwt_required, get_jwt_identity auth_bp = Blueprint('auth', __name__) @auth_bp.route('/api/auth/register', methods=['POST']) def register(): data = request.get_json() if not data or not data.get('username') or not data.get('password'): return {'msg': '用户名和密码不能为空'}, 400 if User.query.filter_by(username=data['username']).first(): return {'msg': '用户名已存在'}, 409 user = User(username=data['username']) user.set_password(data['password']) db.session.add(user) db.session.commit() return {'msg': '注册成功'}, 201 @auth_bp.route('/api/auth/login', methods=['POST']) def login(): data = request.get_json() user = User.query.filter_by(username=data.get('username', '')).first() if not user or not user.check_password(data.get('password', '')): return {'msg': '用户名或密码错误'}, 401 token = create_access_token(identity=str(user.id)) return {'token': token, 'user': user.to_dict()}, 200 @auth_bp.route('/api/auth/me', methods=['GET']) @jwt_required def me(): user = User.query.get(int(get_jwt_identity())) if not user: return {'msg': '用户不存在'}, 404 return user.to_dict(), 200

这里有个实际踩过的坑：create_access_token 的 identity 参数必须传字符串，如果直接传整数，后续从 token 里解析出来的也是字符串，查询数据库时要先做类型转换。我在项目里用 str(user.id) 做了处理，后面 get_jwt_identity() 回来再 int()，避免类型不一致引发的查询 bug。

客户端在拿到 token 后，axios 请求拦截器里统一塞进 Authorization 头。后端通过 jwt_required 装饰器保护需要登录的接口，不需要登录的接口不做限制。这种方式的优点是水平扩展容易，多台后端服务器共用一套校验逻辑，不依赖共享 session 存储，对部署非常友好。

2.3 书评与评论接口的核心实现

书评接口是整个项目的核心。设计书评列表接口时，我特意做了分页和嵌套返回，一次查询把书评携带的书籍信息和用户信息一起返回，前端不用再发额外请求：

@books_bp.route('/api/books/<int:book_id>/reviews', methods=['GET']) def get_book_reviews(book_id): page = request.args.get('page', 1, type=int) per_page = request.args.get('per_page', 10, type=int) pagination = Review.query.filter_by(book_id=book_id)\ .order_by(Review.created_at.desc())\ .paginate(page=page, per_page=per_page, error_out=False) items = [] for r in pagination.items: items.append({ 'id': r.id, 'rating': r.rating, 'content': r.content, 'likes_count': r.likes_count, 'created_at': r.created_at.strftime('%Y-%m-%d %H:%M:%S'), 'user': r.user.to_dict(), 'comments_count': Comment.query.filter_by(review_id=r.id).count() }) return { 'total': pagination.total, 'page': page, 'per_page': per_page, 'items': items }, 200

写评论接口我使用了事务保护，确保点赞数修改的原子性。发布书评、删除书评这几个操作逻辑类似，但有几个容易忽略的点：发布评论前先校验当前用户登录身份；删除书评时必须校验该书评属于当前用户，否则任意用户都能删别人的内容，这是严重越权漏洞；封面图片判断，前端可能传空字符串，后端需要校验 URL 合法性，避免意外数据入库。

评论系统为了支持嵌套回复，我设计了 parent_id 字段，并特意做了一层递归处理。前端的评论树渲染依赖这个字段，如果评论是顶级节点，parent_id 为 None；如果是回复某条评论，parent_id 指向父评论 ID。后端的评论树查询我建议一次性把该书评下所有评论取出来（评论量本身不会特别大），在 Python 层组树结构，避免前端发大量请求。

3. 前端实战：Vue3 组件化与交互细节

3.1 项目初始化与工程结构搭建

前端初始化我直接用 Vite 官方脚手架：

npm create vite@latest frontend -- --template vue cd frontend npm install npm install vue-router@4 pinia axios npm run dev

这里想提醒一个新手常犯的问题：不要在已有项目目录里再嵌套一个 vue 项目，Vite 会检测到当前目录已有内容，初始化会报错或者覆盖文件。我吃过这个亏，实际操作时先把空目录建好，再进目录执行脚手架命令。

Vite 开发环境的端口默认是 5173，后端 Flask 默认跑在 5000。这两个端口不同，浏览器直接发请求必然跨域，所以我在 Vite 配置里加了代理：

// vite.config.js import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { '/api': { target: 'http://127.0.0.1:5000', changeOrigin: true } } } })

这样前端代码里的请求路径直接写 /api/books，开发时 Vite 自动转发到后端。因为浏览器看到的请求是同源的，所以开发环境下根本不需要后端配置 CORS——当然，如果遇到前后端分离部署或者跨域测试，后端还是要配 CORS，这个我在后面的章节专门讲。

3.2 核心组件拆解：书籍卡片与书评列表

前端界面设计我遵循“一切皆组件”的思路。书籍卡片组件 BookCard 负责展示封面、书名、作者、平均评分，点击卡片跳转到书籍详情页。这个组件的 props 设计如下：

<template> <div class="book-card" @click="goDetail"> <img :src="book.cover || defaultCover" :alt="book.title" /> <h3>{{ book.title }}</h3> <p>{{ book.author }}</p> <span class="rating">{{ avgRating }}分</span> </div> </template> <script setup> import { computed } from 'vue' import { useRouter } from 'vue-router' const props = defineProps({ book: { type: Object, required: true } }) const router = useRouter() const avgRating = computed(() => props.book.avg_rating || 0) function goDetail() { router.push(`/books/${props.book.id}`) } </script>

这里有两个细节值得说明。第一，封面图片偶尔会加载失败，所以我加了 defaultCover 兜底图，不然页面上一堆裂图非常难看。第二，在 script setup 里通过 computed 计算展示值，不在模板里写复杂逻辑，取不到评分时显示 0 分，保证页面不会因 undefined 报错。

书评列表组件 ReviewItem 是复用度最高的组件，详情页、个人主页都需要它。单个书评展示用户头像、用户名、评分星标、内容、点赞数和评论数：

<template> <div class="review-item"> <div class="review-header"> <img :src="review.user.avatar || defaultAvatar" class="avatar" /> <span class="username">{{ review.user.username }}</span> <span class="date">{{ review.created_at }}</span> </div> <div class="rating-stars"> {{ '★'.repeat(review.rating) }}{{ '☆'.repeat(5 - review.rating) }} </div> <p class="content">{{ review.content }}</p> <div class="actions"> <button @click="handleLike" :class="{ liked: isLiked }">点赞 {{ review.likes_count }}</button> <button @click="handleReply">回复</button> </div> </div> </template> <script setup> import { ref } from 'vue' import { likeReview } from '../api/reviews' const props = defineProps({ review: { type: Object, required: true } }) const emit = defineEmits(['like', 'reply']) const isLiked = ref(false) async function handleLike() { try { await likeReview(props.review.id) props.review.likes_count += 1 isLiked.value = true emit('like', props.review.id) } catch (e) { alert('请先登录后再点赞') } } function handleReply() { emit('reply', props.review) } </script>

组件内部不直接调全局状态，通过 emit 向父组件抛事件，父组件决定后续逻辑（比如弹出评论框、刷新列表）。这种受控组件模式，让 ReviewItem 变成纯展示 + 交互要素，放到任何页面都能正常工作。点赞按钮的 isLiked 状态我用的是组件内部 ref，没有状态管理也能实现，简单场景真的不需要把每个按钮状态都塞进 Pinia。

3.3 axios 拦截器与收藏、登录状态管理

所有请求统一走封装好的 request.js，这层封装非常关键，至少解决三个问题：token 自动携带、响应错误统一提示、401 时自动跳到登录页。

// src/api/request.js import axios from 'axios' import router from '../router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) request.interceptors.response.use( response => response.data, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') localStorage.removeItem('user') router.push('/login') } const msg = error.response?.data?.msg || '请求失败，请稍后重试' alert(msg) return Promise.reject(error) } ) export default request

登录状态的全局管理我用 Pinia 存了一个 user 对象和登录状态标识。刷新页面后从 localStorage 恢复 user 信息，同时根据是否存在 token 来判断是否已经登录。模板里通过 v-if="isAuthenticated" 控制“写书评/点赞”按钮的显隐，没有登录的用户看到提示后会被引导到登录页。这里我特意没有把 token 放进 Pinia——本地存储 + 拦截器的方案更简单，页面刷新后 token 不会丢，而 Pinia 刷新即清空，反而要重新恢复，多此一举。

3.4 评论树组件与插槽的合理运用

评论区是 Vue 组件递归使用的典型场景。我写了一个 CommentTree 组件，自身递归渲染子评论，用插槽（slot）把“回复”操作暴露给父组件：

<template> <div class="comment-item"> <div class="comment-meta"> <span>{{ comment.user.username }}</span> <span>{{ comment.created_at }}</span> </div> <p>{{ comment.content }}</p> <slot name="actions" :comment="comment"> <button @click="toggleReply">回复</button> </slot> <div v-if="comment.children && comment.children.length" class="comment-children"> <CommentTree v-for="child in comment.children" :key="child.id" :comment="child" @reply="(c) => $emit('reply', c)" /> </div> </div> </template> <script setup> import { ref } from 'vue' defineProps({ comment: Object }) defineEmits(['reply']) const showReply = ref(false) function toggleReply() { showReply.value = !showReply.value } </script>

这种递归组件写法要注意两点：一是必须有一个终止条件，否则 v-for 遍历没有 children 的节点时会无限循环渲染，最终白屏；二是插槽默认内容要能覆盖到，我在插槽里放了默认回复按钮，这样在不同页面复用时可定制。评论实现层级过深的需要控制，我后端组树时限制了最大深度，避免恶意构造超长嵌套链打爆前端渲染。

4. 前后端联调与部署落地

4.1 跨域问题根治方案

开发模式下有 Vite 代理，感觉不到跨域，但一旦前后端分开部署（比如 Flask 跑在云服务器 8000 端口，Nginx 托管 Vue 静态页面），浏览器就会报跨域。后端的跨域解决很简单，Flask-CORS 扩展一句话配置：

from flask_cors import CORS CORS(app, resources={r'/api/*': {'origins': '*'}})

生产环境建议把 origins 换成自己的域名白名单，不要用星号全放行。这里要说清楚一个概念：跨域是浏览器的同源策略，不是后端拒绝请求。如果你用 Postman 测试接口，永远没有跨域问题，但浏览器就严格要求——理解这个机制，排查问题会少走很多弯路。

如果项目里将来要接入实时功能（比如新评论出现时不刷新页面就能看到），可以引入 SSE（Server-Sent Events）或 WebSocket。Flask 里有现成的扩展，但要注意 SSE 连接会同时占用一个 gunicorn worker，如果服务器资源紧张，建议小流量使用或改走轮询。

4.2 Flask 生产部署：gunicorn + Nginx

开发用的 flask run 自带服务器只适合本地调试，绝不能直接拿去生产，并发一上来就崩。生产环境我用 gunicorn 作为 WSGI 服务器，配上 Nginx 做反向代理和静态文件服务。部署命令：

pip install gunicorn gunicorn -w 4 -b 0.0.0.0:8000 app:app

-w 4 表示启动 4 个 worker 进程，具体数量一般建议 CPU 核心数乘以 2 加 1。比如 2 核服务器就开 5 个 worker，这算是比较稳的经验值，开少了并发上不去，开多了内存不够会频繁 OOM。

Nginx 配置核心思路是：/ 路径指向 Vue 打包后的 dist 静态目录，/api/ 路径反向代理到 gunicorn 服务。还要注意一个非常关键的细节：Vue Router 如果使用了 history 模式（URL 里没有 # 号），刷新页面时 Nginx 会因为找不到对应的文件路径返回 404。解决办法是在 server 块里加 try_files，把所有请求统统回退到 index.html：

server { listen 80; server_name your_domain.com; root /var/www/book-review/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

这里有个很容易踩的坑：proxy_pass 后面如果加了路径（比如 http://127.0.0.1:8000/），Nginx 会把 /api 前缀去掉，把请求转发给后端。我最初没搞清楚这个细节，导致 /api/books 被转发成 /books，后端 404 查了半天。实际上不加斜杠是原样转发，加了斜杠会有路径拼写变化，按自己的后端路由规则来选择。我的做法是不加斜杠，保持 /api 前缀原样转发，后端蓝图前缀也是 /api，前后保持统一。

4.3 Vue 打包与部署细节处理

前端部署前执行 npm run build，生成 dist 目录。有几个容易忽略的点：

第一，打包前检查环境变量。如果代码里有直接请求后端地址的地方，建议通过环境变量区分开发环境和生产环境，否则开发时写的 http://127.0.0.1:5000/api 打到线上就废了。

第二，图片资源的路径统一用相对路径或者绝对 CDN 地址。Vue 默认 assetsDir 会把图片打包到 dist/assets 下，如果部署到子路径（比如 http://domain/app/），要用绝对路径或找到对应的 publicPath 配置。

第三，打包后一定先在本地用 Nginx 或者其他静态服务器起一个预览环境测试，不要只跑 npm run dev 觉得没问题就上传。很多问题只有打包产物才会暴露，比如路由模式导致刷新 404、静态资源 404、接口地址写死等。

整个部署流程我整理下来大概是这样：

# 后端 cd backend pip install -r requirements.txt gunicorn -w 4 -b 0.0.0.0:8000 app:app & # 前端 cd frontend npm run build # 把 dist 目录传到服务器 /var/www/book-review/ scp -r dist user@server:/var/www/book-review/ # 配置 Nginx 并 reload nginx -t nginx -s reload

5. 常见问题排查与避坑手册

5.1 高频问题速查

这里面最让我记忆深刻的还是数据库编码问题。第一次部署到 Linux 服务器时，所有中文书评内容都变成问号，折腾了半天发现是 MySQL 连接字符串没加 charset=utf8mb4。SQLAlchemy 连接串写法：

app.config['SQLALCHEMY_DATABASE_URI'] = 'mysql+pymysql://user:pass@localhost/book_db?charset=utf8mb4'

后面建表时把表的默认字符集也指定为 utf8mb4，彻底解决了中文乱码问题。

5.2 实操心得与避坑经验

整个项目做下来，我最想分享几条经验。

第一条，关于密码安全。网上很多教程登录注册直接明文存密码，我强烈建议不要学。哪怕只是个人项目，也要用 werkzeug 的 generate_password_hash 加密存储，这个轮子不用自己造，但能避免很多不必要的风险。万一数据库泄露，用户密码不至于直接暴露。

第二条，关于列表页性能。书评列表如果一次性把所有数据查出来，数据量大了之后接口越来越慢。我用了 SQLAlchemy 自带的 paginate 分页，同时前端接 page 和 total 渲染分页按钮。这个经验的通用性很强，任何列表接口都应该做分页，不然上线之后早晚要回头补。

第三条，关于前后端联调。建议接口文档在写代码之前就定好，字段名、状态码、错误信息格式保持一致。我在做的过程中吃过字段名不统一的亏，前端以为后端返回的是 content，后端字段叫 text，改起来很痛苦。最简单的做法是后端所有接口统一返回格式——成功时 return {'data': ...}，失败时 return {'msg': '...'}，前端封装层集中处理，项目规范统一不少。

第四条，关于 Vue 组件通信。不要动不动就上 Pinia，像书评列表这类数据，父组件统一管理就好。常见的数据流是：书籍详情页（父）在 created 中请求书评 → 把列表传给 ReviewItem 子组件展示 → 子组件点赞后 emit 事件，父组件更新对应的书评点赞数。这个数据流足够清晰，加状态管理反而是过度设计。

第五条，评论数这里有个经典问题：显示评论数时，如果直接用评论表 count 没问题，但评论数据量大的时候，频繁 count 会影响性能。实际项目中可以用冗余字段，在 Review 表里直接加一个 comments_count 字段，发布评论时 update 加 1，删除时减 1。这个优化在项目初期可能不需要，但如果预计评论量很大，可以在架构层面预留这个设计。

6. 还可以这样扩展：让项目变得更有竞争力

如果你打算用这个项目作为作品集或者毕业设计，这里有一些扩展方向，按投入产出比排序：

第一，增加标签系统和内容推荐。书评里提取标签（小说、科幻、传记），首页做“热门标签”入口，再配合评分排序，做成一个简单的推荐页。这个功能技术难度不大，但视觉效果和产品完成度会明显提升。

第二，做用户个人主页。展示用户发布过的所有书评、获赞总数、评论数，配合简单的统计图表（可以用 ECharts 画个柱状图展示最近一个月的书评热度）。这个功能同时用到了“按用户聚合数据”和“可视化”，面试时拿出来讲，比单纯说“我做了个书评网站”有说服力得多。

第三，引入全文搜索。Flask 端用 SQL LIKE 查询勉强够用，但体验一般。可以接 Elasticsearch，或者轻量一点用 SQLite FTS5 或者 MySQL 全文索引。搜索关键词“书名/作者/书评内容”都能命中，体验提升非常大。

第四，管理后台。新增一个简单的 Vue 管理界面，管理员可以审核书评、删除违规评论、管理书籍信息，用 Flask 的 JWT 里加一个角色字段区分普通用户和管理员。这类后台功能是面试官比较认可的实际业务场景。

这些扩展方向都不是空谈，做的时候在现有架构上加蓝图、加路由、加组件就行，不会推翻重来。这也是当初选 Flask + Vue 这套组合最大的好处——边界清楚、扩展成本低，每一步改动都能落在实处。