Python Flask+Vue打造校园二手交易系统：从需求到部署全流程解析

在校园里待过几年的人，大概率都有过这样的经历：想买一本二手教材，翻遍了十几个闲聊群也没找到；想卖掉闲置的自行车，发了几条朋友圈，最后只能在毕业季被收废品的一起称斤拉走。我见过太多同学靠微信群做二手交易，效率和体验都很糟糕——信息几分钟就被淹没，价格不透明，没有评价也没有担保，买卖基本靠运气和自觉。

所以我动手用 Python + Flask + Vue 做了一套校园二手闲置物品租售系统：后端由 Flask 提供接口和业务逻辑，前端由 Vue 构建页面交互，数据落在轻量级 SQLite 数据库中。整套系统支持用户注册登录、商品发布、分类浏览、关键词搜索、收藏留言、交易确认，既能本地跑通，也能部署到普通 Windows 服务器上，非常适合课程设计、毕业设计参考，也适合刚入门的全栈学习者照着做一遍。这篇文章我会按照自己从需求分析、数据库设计、后端接口、前端页面到最终部署上线的完整过程来讲，重点标注那些实际项目里才会遇到的坑，尤其是 Windows 部署时附件路径错误这类问题。

1. 为什么校园二手交易值得自己动手做一套

1.1 二手交易的真实痛点

先聊点真实的校园场景。我见过最典型的情况是：考研结束那几天，宿舍群里全是“出肖秀荣全套”“出英语真题，附笔记”的消息，刷屏速度比聊天还快，真正想买的人根本来不及看，想卖的人也被反复问价搞得疲劳。还有更常见的——二手群只承担“发布”功能，没有搜索、没有分类、没有价格参考，更没有历史记录。同一个物品，有人报价 20，有人报价 80，买家只能靠私聊来回试探。

这样的需求其实非常适合做成一个轻量化系统。二手交易的核心不是社交，而是“信息的结构化匹配”：你发布一条闲置，系统把它拆成标题、分类、成色、价格、图片；别人需要时，按关键词和分类精准筛选，而不是在聊天记录里往上翻几百条。另一个经常被忽视的痛点是交易信任。校园交易虽然大多线下面对面，但卖家的历史记录、买家浏览过哪些商品、卖家是否及时下架已售物品，这些基础信息如果完全没有记录，纠纷一来就是一笔糊涂账。

我决定自己做这套系统的原因也很简单：市面上不是没有闲鱼，但校园场景有它的特殊性——同一栋宿舍楼、同一个校区内的交易更讲究效率；很多东西只在毕业季和开学季集中流动；价格低、频次高、商品更新快。一套针对校园优化的轻量系统，比通用二手平台更贴合这个场景。哪怕是作为练手项目，它也比普通的“图书管理系统”有价值得多，因为整个业务流程更真实、更完整。

1.2 技术选型背后的取舍

选型是动手前必须想清楚的第一步，这里没有唯一正确答案，只有“适不适合你当前的目标”。我最终选了 Python + Flask + Vue + SQLite，背后的判断是这样的：

• Flask 而不是 Django：Flask 足够轻，路由、蓝图、上下文等机制很直观，特别适合用来理解 Web 后端最核心的东西——HTTP 请求怎么进来、怎么路由、怎么返回 JSON。Django 功能强大但自带 Admin、ORM、中间件等一堆概念，新手很容易陷入“照着教程搬但不知道在搬什么”的状态。对校园二手系统这种中等复杂度的项目，Flask 完全够用。
• Vue 而不是 React：Vue 对中国开发者来说文档和社区更友好，模板语法直观，单文件组件（SFC）让页面结构和样式集中在一起，配合 Element Plus 这类组件库，写后台管理系统或者商品列表这类界面速度很快。React 的生态和灵活性也很好，但如果目标是“快速看到成品”，Vue 的上手曲线更平缓。
• SQLite 而不是 MySQL：这套系统的数据量，撑死几千个用户、几万条商品记录，SQLite 单文件存储、零配置、备份就是复制一个文件，对学生项目来说再合适不过。真到了并发写入量很大、需要多机部署的阶段，再平滑切到 MySQL 也不难，因为大多数代码走的是 ORM，数据库方言差异被挡住了。

换个角度说，选型还要考虑“你最终能跑多远”。我见过很多同学一上来就上微服务、Redis、消息队列，结果折腾半个月连注册登录都没跑通。决定项目成败的往往不是技术栈多先进，而是你能不能把它完整地部署出来、给别人用上。下面的表格是我当时做的对比，建议你也列一张：

对比维度	Flask 方案	Django 方案	我的选择理由
学习曲线	平缓，能看清底层逻辑	较陡，概念多	想先把 Web 原理吃透
项目体积	精简，按需扩展	完整但偏重	校园二手系统不需要全栈框架的重量
数据库	SQLite 起步，可换 MySQL	默认 PostgreSQL 体系	SQLite 零运维压力
前端配合	纯 JSON API，天然适合 Vue	服务端模板渲染更强	想练前后端分离

这套选型逻辑不是唯一的，但它是“用最少的时间得到一个可演示、可部署成品”的稳妥路线。如果你已经有 Django 经验，用 Django 做也没问题；如果后端是 Java 背景，Spring Boot 同样可以。关键是先明确自己到底要练什么、要在多长时间内交出什么。

2. 从需求到功能清单：动手之前先画清楚业务流程

2.1 核心功能模块

很多人写代码失败，不是不会写语法，而是需求根本没想清楚就开干，写着写着发现这里缺块表、那里少个状态。我在动工之前，把所有功能按“交易闭环”拆了一遍：

• 用户模块：注册、登录、退出，密码用哈希存储，Session 或 Token 管理登录态，个人中心展示我发布的、我收藏的、我买到的。
• 商品模块：发布闲置（标题、描述、分类、价格、原价、成色、图片、联系方式）、编辑下架、商品列表、详情页、分类筛选、关键词搜索、排序。
• 互动模块：收藏商品、对商品留言、查看卖家信息、站内私信（1.0 版本可以先用留言代替）。
• 交易模块：买家确认“我想要”、卖家确认“已成交”、商品状态自动变为已售下架。
• 管理模块：管理员后台可审核违规商品、处理举报，1.0 阶段先做最基础的商品下架能力。

这五个模块不是平级的，优先级差别很大。我当时给排了个序：

优先级	功能	说明
P0	注册登录、商品发布、商品列表、详情页	没有这些，系统连基本闭环都跑不通
P1	搜索筛选、收藏留言、状态流转	提升可用性，让交易可操作
P2	数据统计、后台管理、私信通知	属于锦上添花，可以后续迭代

我强烈建议你不要一开始就追求功能齐全。先把“注册-发布-浏览-联系-成交-下架”这条主线跑通，哪怕界面丑一点，也能真实用了。有了真实用户输入的数据，再谈优化和加功能，方向才会对。

2.2 核心流程设计

需求清单只回答了“做哪些功能”，流程设计则要回答“用户怎么走完一次交易”。我把核心流程画成了很朴素的路径：

1. 新用户注册登录，填写昵称、手机号、微信号。
2. 发布闲置：选择分类、填写标题描述、上传图片、设置价格和成色。
3. 买家在首页按分类浏览，或用关键词搜索，按最新发布/价格排序。
4. 进入商品详情，查看图片和卖家信息，点击收藏或留言。
5. 买家与卖家通过站内留言或展示的微信号联系，约线下交易。
6. 交易完成后，买家或卖家在订单记录中标记“已成交”，商品自动下架。
7. 如果商品被管理员发现违规，可以强制下架并通知发布者。

这里有一个很重要的设计决定：为什么同时保留“站内留言”和“展示联系方式”两条通道？我一开始以为学生都会用站内留言沟通，省事又留痕。后来和几个同学聊了才发现，大家更习惯加微信，因为要看实物照片、约时间地点，微信更顺手。但纯展示联系方式也有问题：平台看不到交易沟通过程，纠纷难以追溯。

所以最好的做法是两条通道并存：站内留言作为平台内的记录，方便日后追溯；联系方式作为线下交易辅助，真正提高成交效率。这个原则很多二手平台也是这么做的，你设计时不要只图“管理方便”而砍掉用户习惯的那条路。

流程里还有一个容易被忽略的点：商品状态机。一件商品要从“在售”变成“已下架”“已成交”“违规下架”，状态必须存在数据库字段里，而不是发布者删掉这条记录。否则交易历史、买家收藏、后台统计都会乱套。我建议从第一天起就设计好status字段，而不是等项目跑起来再补。

3. 数据库表结构和 Flask 后端接口的实现要点

3.1 表结构怎么设计才够用

数据库是整个系统的地基。我的原则是“宁缺毋滥，但关键的关联和状态字段不能少”。全套系统用 SQLite 落库，ORM 选 Flask-SQLAlchemy，这里是我整理出来的核心表结构：

-- 用户表 CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username VARCHAR(64) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, nickname VARCHAR(64), avatar VARCHAR(255), phone VARCHAR(20), wechat VARCHAR(64), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 商品表 CREATE TABLE items ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER NOT NULL, title VARCHAR(100) NOT NULL, description TEXT, category VARCHAR(50), price NUMERIC(10, 2), original_price NUMERIC(10, 2), quality VARCHAR(20), -- 全新/几乎全新/轻微使用/明显使用痕迹 images TEXT, -- 存 JSON 数组或逗号分隔的图片路径 contact_wechat VARCHAR(64), contact_phone VARCHAR(20), status VARCHAR(20) DEFAULT 'on_sale', -- on_sale/sold/off_shelf/rejected view_count INTEGER DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES users(id) ); -- 收藏表 CREATE TABLE favorites ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER NOT NULL, item_id INTEGER NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE(user_id, item_id) ); -- 留言表 CREATE TABLE messages ( id INTEGER PRIMARY KEY AUTOINCREMENT, item_id INTEGER NOT NULL, user_id INTEGER NOT NULL, content TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 交易记录表 CREATE TABLE orders ( id INTEGER PRIMARY KEY AUTOINCREMENT, item_id INTEGER NOT NULL, buyer_id INTEGER NOT NULL, seller_id INTEGER NOT NULL, status VARCHAR(20) DEFAULT 'pending', -- pending/confirmed/cancelled/completed created_at DATETIME DEFAULT CURRENT_TIMESTAMP );

几个细节值得强调：

• images字段存图片路径的 JSON 数组，而不是单独建一张商品图片表。校园二手场景下，一个商品 3 到 5 张图就够，一张字段搞定查询也简单。如果以后要做多图集管理，再拆表也不迟。
• price用NUMERIC(10, 2)而不是浮点数，避免展示时出现 19.999999 的问题。
• status字段一定要加索引，因为商品列表页最核心的查询就是WHERE status = 'on_sale'。
• UNIQUE(user_id, item_id)在收藏表里可以防止重复收藏，这比在代码里判断更可靠。

3.2 Flask 项目分层与接口实现

Flask 项目最怕写成一个超大的app.py。我当时把项目按蓝图（Blueprint）拆成几个模块，好处是路由和模型不会互相纠缠，后期加功能也方便：

flask-backend/ ├── app.py # 创建 app、注册蓝图、数据库初始化 ├── config.py # 配置项：数据库路径、上传目录、密钥 ├── models.py # 所有 ORM 模型 ├── requirements.txt ├── uploads/ # 用户上传的图片 └── blueprints/ ├── auth.py # 注册、登录、退出 ├── item.py # 商品 CRUD、搜索、筛选 ├── user.py # 个人中心、我发布的、我收藏的 └── order.py # 收藏、留言、订单状态流转

写接口时有一个原则：后端返回 JSON，前端只消费 JSON。比如商品列表接口，我当时的写法大概是这样：

from flask import Blueprint, request, jsonify from models import Item, db item_bp = Blueprint('item', __name__) @item_bp.get('/api/items') def list_items(): page = request.args.get('page', 1, type=int) per_page = request.args.get('per_page', 12, type=int) keyword = request.args.get('keyword', '', type=str) category = request.args.get('category', '', type=str) query = Item.query.filter(Item.status == 'on_sale') if keyword: query = query.filter(Item.title.contains(keyword)) if category: query = query.filter(Item.category == category) pagination = query.order_by(Item.created_at.desc()).paginate( page=page, per_page=per_page, error_out=False ) items = [item.to_dict() for item in pagination.items] return jsonify({ 'items': items, 'total': pagination.total, 'page': page, 'pages': pagination.pages })

这里有两个容易犯的低级错误：第一，接口返回的分页数据一定要带上total和pages，前端分页组件需要它们，不然不好算总页数；第二，列表接口不要直接给前端传 ORM 对象，要有一个to_dict()方法明确告诉调用方返回了哪些字段，否则容易把内部字段也暴露出去。

关于密码安全要单独说一下：不能用明文密码存数据库。我当时用werkzeug.security的generate_password_hash和check_password_hash，注册时存哈希，登录时校验哈希，登录态用 Flask 的session管理，开启SESSION_COOKIE_HTTPONLY。安全这块不用做得多花哨，但底线必须有，尤其是公开部署的项目。

3.3 图片上传与静态资源路径：这里埋着一个大坑

商品图片是二手系统的门面，但图片上传和访问路径，恰恰是最容易出问题的地方。我一开始的做法很天真：把上传的图片放到 Flask 项目目录下的static/uploads，然后通过/static/uploads/xxx.jpg访问。本地开发一切正常，部署到 Windows 服务器之后问题接踵而至。

第一个坑是路径拼写。Windows 的路径分隔符是反斜杠\，而浏览器 URL 用的是正斜杠/。如果你在代码里手动拼字符串，比如save_path = upload_dir + '\\' + filename，然后把save_path存到了数据库里，那么前端拿到的图片地址就是http://host/static/uploads\xxx.jpg，浏览器根本识别不了。这不是什么玄学，就是路径分隔符没统一。

第二个坑是动态获取路径。有些代码写成os.getcwd()拼接路径，开发时项目在 D 盘某个目录，部署后被移到 E 盘另一个目录，图片全部 404。正确做法是让上传目录基于固定配置，而不是依赖当前工作目录。

我当时最终的修复方案是：

import os from flask import Flask BASE_DIR = os.path.dirname(os.path.abspath(__file__)) UPLOAD_DIR = os.path.join(BASE_DIR, 'uploads') ALLOWED_EXTENSIONS = {'png', 'jpg', 'jpeg', 'gif', 'webp'} # 保存图片 def save_image(file): ext = file.filename.rsplit('.', 1)[-1].lower() if ext not in ALLOWED_EXTENSIONS: return None, '不支持的图片格式' filename = str(uuid.uuid4()).replace('-', '') + '.' + ext file.save(os.path.join(UPLOAD_DIR, filename)) return f'/uploads/{filename}', None

关键点有三条：

• 用os.path.abspath(__file__)定位项目根目录，不管从哪个目录启动，路径都不会跑偏。
• 上传文件名不要用用户原始文件名，改用uuid生成唯一名字，避免重名覆盖和路径穿越问题。
• 数据库里存的是 URL 形式的/uploads/xxx.jpg，而不是服务器磁盘路径。文件保存和 URL 访问是两回事，混淆了必出问题。

静态资源访问这一块，Flask 需要显式指定：

app = Flask(__name__, static_folder='.', static_url_path='')

这样做的意义是：让 Flask 既能正常提供/uploads/下的图片，也能在后续托管 Vue 打包后的静态文件，一个服务搞定前端和后端，部署时省去配 Nginx 的步骤。当然，如果你有精力配 Nginx 做静态文件服务，性能会更好，但在校园场景和课程设计里，Flask 直接托管完全足够。

4. Vue 前端的关键交互实现

4.1 项目初始化和目录组织

前端用的是 Vue 3 + Vite。我之所以不用 Vue CLI 而用 Vite，是因为 Vite 基于 ES Module，冷启动和热更新都比 Webpack 快非常多，对开发体验改善是质的飞跃。初始化命令很简单：

npm create vite@latest vue-frontend -- --template vue cd vue-frontend npm install npm install vue-router@4 axios element-plus

项目里的目录结构我建议这样分：

src/ ├── api/ # axios 请求封装，按模块拆分 │ ├── request.js │ ├── auth.js │ └── item.js ├── router/ # 路由配置 ├── views/ # 页面级组件 │ ├── Home.vue # 商品列表 │ ├── Login.vue │ ├── Register.vue │ ├── ItemDetail.vue │ ├── Publish.vue # 发布商品 │ └── Profile.vue # 个人中心 ├── components/ # 通用组件 └── store/ # 如果要管理登录态，可以放 Pinia

很多新人容易把页面逻辑全堆在一个组件里，一个.vue文件几千行，后期改起来非常痛苦。我的习惯是：页面组件只负责布局和交互，数据请求全部走api/里的模块，这样接口调整时只改一处。

4.2 请求封装与跨域处理

axios 封装是前端项目的标配。我当时的封装思路是：统一设置基础路径、自动携带 Session Cookie、统一处理错误码。登录态这东西，Flask 默认用的是 Cookie Session，只要前端请求带上withCredentials，后端就能识别当前用户。

// api/request.js import axios from 'axios'; import { ElMessage } from 'element-plus'; const request = axios.create({ baseURL: '/api', timeout: 8000, withCredentials: true }); request.interceptors.response.use( (response) => response.data, (error) => { const status = error.response?.status; if (status === 401) { ElMessage.error('请先登录'); window.location.href = '/login'; } else { ElMessage.error(error.response?.data?.message || '请求失败'); } return Promise.reject(error); } ); export default request;

与之配套的是 Vite 开发服务器的代理配置。开发时前端跑在 5173 端口，后端跑在 5000 端口，浏览器直接请求 Flask 接口必然遇到跨域问题。解决方式不是在后端装flask-cors（当然那也是一种方案），而是在 Vite 里配置代理：所有/api开头的请求都转发到 Flask。

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

这个方案有一个额外好处：开发环境前端请求的 URL 是/api/items，部署后如果前端被 Flask 托管，请求的 URL 还是/api/items。前后端接口路径完全一致，不需要因为环境切换去改代码。我见过不少项目开发时写死了http://localhost:5000/api，部署到服务器上又改配置，完全是自己给自己找麻烦。

4.3 商品列表、详情页和发布表单的实现思路

商品列表页是整个系统流量最大的页面。我当时做了三个核心能力：分类标签筛选、关键词搜索、分页加载。交互逻辑很简单：筛选条件变了，就重新请求第一页数据；点击分页，带上当前的筛选条件请求对应页的数据。为了避免频繁请求，搜索框加了一个debounce（防抖），用户停止输入 500 毫秒后才发起请求。

商品详情页需要注意图片展示和联系方式呈现的平衡。多图我会用 Element Plus 的el-carousel轮播，主图大图展示，下面横排缩略图。联系区域放两个按钮：一个“留言咨询”，弹出一个对话框填写留言；一个“查看卖家微信”，点击后显示微信号文本，方便复制添加。要防止页面一加载就把所有图片原图加载出来，轮播图建议用懒加载，提升弱网环境下的打开速度。

发布表单我用了 Element Plus 的el-form，校验规则包括：标题必填且不超过 40 字、价格必填且大于等于 0、至少上传一张图片。图片上传使用el-upload，手动控制请求，选择图片后先本地预览，用户确认提交时再一次性把所有图片上传到后端。这里有一个细节：不要把图片上传和商品信息提交拆成两步独立操作，否则用户填了一半放弃，会产生一批没有关联到商品的孤儿图片。更好的做法是把图片作为表单数据的一部分，连同商品信息一起用FormData提交，后端一次处理完整事务。

5. 本地联调与部署上线：Windows 服务器的实战记录

5.1 本地跑通联调

本地开发时，我习惯开两个终端：一个跑 Flask，一个跑 Vite。Flask 启动要监听所有网卡，方便手机在同一局域网内测试：

flask --app app run --host=0.0.0.0 --port=5000

前端则执行npm run dev，浏览器访问 Vite 输出的地址。因为代理已经配好，页面里所有/api请求都会被转发到后端的 5000 端口，前后端联调基本无感。建议你在这一步就先把“发布商品-首页可见-查看详情-留言”这条链路完整走一遍，确认没问题再考虑部署，免得把联调问题误当成部署问题排查。

5.2 Windows 服务器部署的完整步骤

这里说一下我后来在 Windows Server 上部署的实操流程。整个过程不依赖 Docker（很多时候校园环境里没有现成的 Docker 环境），也不用 Nginx，纯靠 Python 生态自带的能力就能跑起来：

1. 准备 Python 环境。服务器安装 Python 3.10 或 3.11，安装时务必勾选 “Add Python to PATH”，否则命令行里找不到python。
2. 上传项目文件。把后端的app.py、models.py、blueprints/、requirements.txt以及前端构建产物都传上去。
3. 创建虚拟环境：

cd D:\projects\campus-market python -m venv venv venv\Scripts\activate pip install -r requirements.txt

4. 构建前端。本地执行npm run build，生成的dist目录整个传到服务器，放到 Flask 项目的static目录关联的位置。Flask 这边需要加一个“兜底路由”，让所有非/api和非/uploads的请求都返回index.html：

@app.route('/') def index(): return send_from_directory('static', 'index.html') @app.errorhandler(404) def not_found(e): path = request.path if path.startswith('/api') or path.startswith('/uploads'): return jsonify({'message': '资源不存在'}), 404 return send_from_directory('static', 'index.html')

这个兜底处理非常关键。Vue Router 如果是history模式，直接访问/item/3这种地址时，服务器是没有这个文件的，必须返回index.html让前端路由接管。不然一刷新详情页就是 404。

5. 用 Waitress 启动服务。Flask 自带的开发服务器只能用于调试，生产环境要换 Waitress，它是 Windows 平台下非常靠谱的纯 Python WSGI 服务器：

pip install waitress waitress-serve --host=0.0.0.0 --port=80 --call app:create_app

我用的是--call app:create_app的写法，前提是app.py里定义了工厂函数create_app，这样项目结构更干净，测试和部署都方便。

6. 开机自启。Windows 服务器上不能像 Linux 一样随便用 systemd。我用 NSSM 把 Waitress 注册成了系统服务，这样即使服务器重启，系统也能自动恢复运行。这一步如果不想用额外工具，也可以写一个.bat脚本丢进启动文件夹，但 NSSM 管理服务状态、看日志都更舒服。

这套流程拿到一台干净 Windows 服务器上，从头到尾大概半小时能跑通。核心思路就一句话：让 Flask 同时托管前端静态资源和后端 API，用 Waitress 提供稳定的 WSGI 服务，结构简单，便于排错。

5.3 附件路径错误：部署时最经典的坑

这部分我单独拎出来说，因为太典型了。我最初在本地发布商品、上传图片，一切正常。部署到 Windows 服务器后，出现了一个奇怪现象：新上传的图片当天能访问，服务器重启后有些图片 404 了，而且上传成功后如果立刻刷新页面，偶尔也会显示裂图。

排查过程我一步步讲：

• 第一步：确认图片文件到底存到了哪。我在服务器上打开uploads目录，发现文件明明存在，数据库里的路径也能对上。那为什么访问不了？这一步排除了“上传失败”的可能。
• 第二步：检查 URL 和磁盘路径的映射关系。问题来了。我数据库里存的是static/uploads/20250401/xxx.jpg这种相对路径，而 Flask 的static路由已经配置了。我把请求 URL 和磁盘结构对比后发现：本地项目根目录叫campus-market，服务器上我为了整洁，把项目根目录改成了market-server。代码里如果用了os.path.join(os.getcwd(), 'static')之类依赖“当前工作目录”的写法，本地跑没错，换到服务器上一启动就都不对。
• 第三步：检查 Windows 路径分隔符。发现一些图片的 URL 里带上了\，就是因为存路径时用了os.path.join，在 Windows 上拼出了反斜杠路径，浏览器不认。

最终的修复方案是：在config.py里定义基于项目绝对路径的上传目录和静态目录，保存图片时只存 URL 路径，访问时靠 Flask 静态路由解析，绝不依赖os.getcwd()，也绝不在数据库里存磁盘绝对路径。修完之后，图片上传、重启、刷新全部正常。

这个坑的经验可以总结成一句话：凡是涉及文件路径的代码，必须在项目上线前做一次“换目录启动”测试。本地怎么启动，服务器就怎么启动，如果项目根目录换了还能正常工作，才说明路径处理是健壮的。

6. 上线一两周后的优化方向与个人体会

6.1 搜索体验的小优化

系统跑起来之后，最影响日常体验的是搜索。初始版本我用的是Item.title.contains(keyword)，也就是数据库LIKE模糊匹配。这个方案的问题很明显：搜“高数”搜不到“高等数学”，搜“山地车”也搜不到“捷安特”，因为关键词对不上。

我第一次优化做了两件事。第一件是搜索范围和权重调整：标题命中权重最高，描述命中权重其次，分类命中也可以算进去。第二件是引入简单的关键词归一化：把用户输入的空格、特殊符号去掉，统一小写；再维护一个同义词映射表，比如“单车”和“自行车”能够互相匹配。这套朴素方案虽然不如向量检索那样“聪明”，但在校园二手这种封闭语料环境下效果已经很好。

另外一个体验点：搜索结果为空时，不要冷冰冰地显示“没有找到相关商品”。我当时加了“猜你想看的同类热门商品”兜底，按分类推荐浏览数最高的几条，用户就不会一搜不到就走。发布端也要做“无效信息过滤”的小动作，比如联系方式重复、标题全是大写字母、包含明显广告词，提交时直接提示修改。这不是为了刁难用户，是为了保证搜索结果的质量。

6.2 后续可以扩展的方向

等核心闭环稳定后，我会建议按用户价值从高到低去扩展，而不是想到什么做什么：

• 站内私信：从“留言板”升级为“一对一会话流”，成交前沟通更私密流畅。消息表需要加from_user_id、to_user_id、is_read这些字段，再配合 WebSocket 能做到实时提醒。
• 信用与评价体系：每次交易完成后，买卖双方互评，形成个人信用分。校园圈子不大，信用评价对促成交易很有说服力。
• 担保交易：这个功能工程量不小，需要接入支付或校内校园卡系统，适合作为进阶版本。普通课程设计不必强求。
• 微信小程序端：Vue 3 的代码可以通过 uni-app 或 Taro 迁移到小程序，复用大部分逻辑。学生用手机访问网站的习惯其实不如打开小程序方便，如果想让项目“落地”，这是最有价值的一步。

6.3 我的几点心里话

做完这个项目，我最大的体会是：千万不要一开始就过度设计。我第一版也想过是不是要用 Redis 做缓存、用 Docker 做容器化、用 Nginx 做负载均衡，后来冷静下来发现，一套几百人使用的校园系统根本不需要这些东西。你的时间应该花在把核心业务流程做得稳定、把页面交互做得顺手、把部署流程做得可复现上。真正的学习不是堆技术名词，而是把一个系统从想法变成能被同学真实使用的产品。

技术实现上，有几个看似小但影响巨大的细节我再强调一遍：密码必须哈希存储；上传文件名必须唯一化；数据库路径不能依赖当前工作目录；前端路由 history 模式必须有兜底路由；部署之前先做一次换目录启动测试。把这些做好了，你的项目就不再是“能跑”，而是“能长期用”。

最后说一句题外话：如果你准备拿这个项目去答辩或写进简历，建议提前准备好“技术选型理由”和“遇到的最大坑及解决方案”这两个问题的答案，因为这是别人最容易追问的地方。我正是因为被问过太多次，才把附件路径错误和 Vite 代理跨域那两段经验沉下来，写成了这篇文章。