1. 项目整体定位与技术栈选型

校园二手闲置物品共享平台，这个标题拆开来看其实包含了三层业务含义：面向校园用户群体、处理闲置二手物品交易、强调"共享"这个互动属性。很多同学拿这类题目练手或者做毕业设计，但我实际带过不少项目后发现，真正把这三层含义都吃透的很少。

先说校园这个场景。校园用户有两个明显特点：一是地域高度集中，宿舍区、教学楼、食堂就是核心活动半径；二是信任链很强，同校学生之间的交易天然比社会闲鱼更有安全感。这意味着平台不需要做得太重，不需要复杂的物流体系、担保交易、信用评分这些大而全的东西，反而应该把精力放在"校内信息高效匹配"上。二手物品又决定了业务特征是低频但刚需——一个学生一学期可能就卖两三件闲置，但每件都有真实的处理诉求。

再看"共享"这个词。它不只是做一个信息发布栏，而是强调物品在校园内的流转效率。所以平台功能上要至少覆盖发布、浏览、搜索、详情、联系、下架这一整条链路，最好还能加留言询问和收藏功能，让物品信息活起来。

为什么选Node.js而不是Java Spring Boot或者Python Django？这个选择背后是成本和效率的权衡。Node.js做这类CRUD密集型的Web应用有几个实打实的优势：

• 单语言全栈：前端用Vue/React，后端用Node.js，整个项目统一JavaScript语言，心智负担小很多。
• 开发效率极高：Express框架几行代码就能搭起路由，配合Nodemon热更新，改代码刷新即生效，非常契合课程设计和中小型项目快速开发的需求。
• npm生态成熟：JWT认证、文件上传、数据库ORM、WebSocket实时通信，都能找到久经考验的成熟包，站到巨人的肩膀上。
• I/O密集型场景匹配：二手平台的每一次操作都是大量小请求（列表查询、详情查看、图片加载），Node.js事件驱动的非阻塞I/O模型在这个场景下表现很好。

当然，Node.js也不是万能的。如果你要做的平台涉及复杂事务、高并发写入、精细的权限审计，那Spring Boot可能更合适。但就校园二手这个体量——几百个用户、日均几百次请求——Node.js的性能绰绰有余，真正的瓶颈在业务设计是否合理。

2. 环境搭建与npm经典问题排查

现在写Node.js项目，第一道坎反而是环境安装。我从热搜词里看到大量"npm无法加载文件ps1"、"因为在此系统上禁止运行脚本"这类问题，这几乎是每个Windows环境新手都逃不掉的坑。

2.1 Node.js正确安装与版本选择

记住一个原则：不要追求最新版本，选LTS稳定版。很多新手一上来就装最新的Node 22甚至24，结果某些依赖包（尤其是node-sass这种老牌的）编译不过去，直接劝退。当前阶段建议用Node 18 LTS或者Node 20 LTS，生态兼容性最好。

Windows安装很简单：去官网下载msi安装包，一路Next就行。有两个细节要注意：

• 安装路径尽量避开带空格的目录，比如D:\Program Files (x86)\nodejs\这种。虽然Node本身能正常工作，但后续很多命令行工具、脚本可能会因为空格路径解析出幺蛾子。
• 安装完成后，Node会自动把node.exe所在目录加进系统PATH环境变量，理论上重启终端就可以直接用node -v验证。

验证是否装好，打开命令行依次执行：

node -v npm -v

如果都输出了版本号，说明安装成功。这只是第一步，真正的问题是后续。

2.2 npm执行策略报错的两种解法

热搜词里那个npm : 无法加载文件 D:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本的报错，根源在于Windows PowerShell的ExecutionPolicy策略默认是Restricted（禁止任何脚本运行）。而npm的入口文件npm.ps1就是一个PowerShell脚本，所以直接执行会被拦截。

这个问题的解法有两种，我建议新手直接用第一种：

解法一：改执行策略（一劳永逸）

右键开始菜单，选择"Windows PowerShell(管理员)"，执行：

set-ExecutionPolicy RemoteSigned

选Y确认即可。这个策略的意思是：本地创建的脚本可以运行，从网上下载的脚本必须经过签名认证才能运行。既解决了npm的使用问题，又保留了基本的安全防护。

解法二：改用Command Prompt（治标不治本）

不想动系统设置的话，Windows系统可以切换使用cmd（命令提示符）来执行npm命令。cmd运行的是npm.cmd而不是npm.ps1，完全不受PowerShell执行策略限制。但这只是绕开了问题，后面如果你要用PowerShell跑自动化脚本，还是会踩坑。

这里还有个隐藏很深的点：这类报错往往同时伴随node版本和项目要求不一致的问题。比如你下载的项目.nvmrc要求Node 16，但你系统装的是Node 20，那跑起来多半会报语法错误或依赖不兼容。推荐装个nvm-windows做版本管理，随时切换：

# 安装指定版本并切换 nvm install 18.20.4 nvm use 18.20.4

2.3 npm镜像源与全局配置优化

国内开发环境，npm官方源访问极慢，别名是实际使用中最大的痛点。建议直接配置为国内镜像，这一步做完，后面安装依赖的体验完全不一样：

npm config set registry https://registry.npmmirror.com # 验证是否生效 npm config get registry

看到输出https://registry.npmmirror.com就说明配置成功了。顺便可以把cache目录也改一下（可选），给C盘减减负：

npm config set cache "D:\npm-cache"

还有个小技巧：新项目建议在根目录创建.npmrc文件写入镜像源配置，这样项目跟着走，团队协作时别人clone下来也不会踩源的坑。

2.4 安装依赖包时的编译报错处理

这个坑是热搜词里没有直接提到但极其常见的。执行npm install时，如果依赖中包含需要原生编译的包（比如bcrypt密码加密库、sharp图片处理库），在Windows上经常报node-gyp相关错误。

根因是这些包需要C++编译工具链，而Windows默认没装。解决办法：

# 以管理员身份运行 npm install --global windows-build-tools

或者干脆避坑，选型时用纯JavaScript实现的可替代包。比如密码加密用bcryptjs而不是bcrypt，图片压缩用jimp而不是sharp。虽然性能稍微逊色一些，但在校园项目这个量级上完全感知不到差异，省去了大量环境折腾的时间。

3. 平台核心业务设计与数据库建模

二手平台的技术架构不复杂，核心在数据模型是否贴合业务语义。这里我给出经过实际项目验证过的设计，并解释每个选择的理由。

3.1 数据库选型与ER设计

数据存储方案上，最自然的组合是MySQL + Sequelize ORM。MySQL成熟稳定，用Navicat或Workbench可视化操作方便；Sequelize让表关系定义、增删改查、自动建表都很省事。

核心数据模型我拆成了6张表：

用户表(User)

商品表(Product)

订单表(Order)、收藏表(Favorite)、留言表(Comment)、消息表(Message)，分别记录交易状态、收藏关系、商品下的询问内容和买家卖家之间的沟通记录。

这里有两个容易忽略的设计点得专门说：

• 商品状态机：status字段不要只埋0和1，一定要预留"下架"状态。实际业务中经常出现"买家付了钱但卖家改主意不卖"的情况，没有下架状态就只能删数据，而删数据会连带把交易记录和留言一起干掉，后期统计数据会很难看。
• 消息表独立设计：很多二手平台把聊天信息直接塞在留言里，这在校园场景下体验很割裂。留言是"公开的询问"（大家都在看），消息是"私聊"（只有双方可见），语义完全不同，要分表。

3.2 为什么用JWT而不是Session

用户认证方案我直接推荐JWT（JSON Web Token），这也是当前主流Node.js项目的事实标准。

Session方案的问题在于服务器需要维护会话状态。用户登录后，后端要存一份session记录，客户端要存一个sessionId，请求时带上。这套机制在前后端不分离的年代够用，但放在Vue单页应用 + API接口这种模式下，会有跨域携带Cookie的麻烦，还得处理session持久化问题。

JWT的思路完全反过来——服务器不存状态，把用户信息加密签成一个token发给前端，前端每次请求把这个token放在Authorization请求头里，后端验签通过就放行。好处是显而易见的：

• 后端服务天然无状态，换机器、重启、水平扩容都不影响已登录用户
• 移动端和Web端都能用同一套认证逻辑
• 配合中间件，权限校验实现极其优雅

实现上推荐用jsonwebtoken包：

const jwt = require('jsonwebtoken'); // 登录成功时签发，expiresIn设7天方便校园用户 const token = jwt.sign( { id: user.id, role: user.role }, process.env.JWT_SECRET, { expiresIn: '7d' } ); // 请求中校验 const authMiddleware = (req, res, next) => { const token = req.headers.authorization?.replace('Bearer ', ''); if (!token) return res.status(401).json({ message: '未登录' }); try { req.user = jwt.verify(token, process.env.JWT_SECRET); next(); } catch (err) { return res.status(401).json({ message: '登录已过期' }); } };

有一个细节要注意：JWT_SECRET绝不能硬编码在代码里。项目根目录建.env文件存放，用dotenv加载，同时把.env加进.gitignore。

密码存储也是个容易被新手忽视的点。教材里教的MD5加密已经完全不安全了，撞库工具几秒就能跑出来。推荐用bcryptjs：

const bcrypt = require('bcryptjs'); // 注册时：生成盐并哈希，saltRounds设10即可 const hashedPassword = await bcrypt.hash(password, 10); // 登录时：比较明文密码与存储的哈希 const isMatch = await bcrypt.compare(password, user.password);

算一下为什么saltRounds设10：这个值越高加密越慢，10大约需要100ms左右，用户几乎无感知，但已经足够让暴力破解变得不划算。

3.3 RESTful API规划

结合二手平台业务，我把接口按模块拆清楚：

认证模块

• POST /api/auth/register注册
• POST /api/auth/login登录
• GET /api/auth/profile获取个人信息
• PUT /api/auth/profile修改资料

商品模块

• GET /api/products分页获取商品列表，支持关键词、分类、价格区间筛选
• GET /api/products/:id商品详情，浏览量+1
• POST /api/products发布商品（需登录）
• PUT /api/products/:id编辑商品（仅本人）
• DELETE /api/products/:id删除商品（仅本人）
• PUT /api/products/:id/status修改状态（上架/下架/标记已售）

互动模块

• GET /api/products/:id/comments获取商品留言
• POST /api/products/:id/comments添加留言
• POST /api/favorites/:id收藏/取消收藏
• GET /api/favorites我的收藏列表

接口设计遵循RESTful语义，用HTTP动词表达操作意图，请求参数和响应数据统一JSON格式。响应结构我习惯统一成{ code: 0, data: ..., message: 'success' }这种壳子，code为0表示成功，非0表示各类错误码。有人喜欢直接用HTTP状态码表达一切，但我觉得业务里保留一层应用码，前端处理起来更方便。

4. 后端服务实现与业务逻辑拆解

这一部分我挑几个关键实现来展开，这些是实际开发中工作量最大、也最容易出问题的地方。

4.1 项目结构与中间件设计

合理的项目目录不仅是为了好看，更是为了后期迭代时能快速定位代码：

project-root/ ├── config/ # 配置文件、密钥、数据库连接 ├── models/ # Sequelize数据模型定义 ├── routes/ # 路由定义，按模块拆分 ├── controllers/ # 控制器，处理业务逻辑 ├── middlewares/ # 中间件（认证、错误处理、上传） ├── utils/ # 工具函数 ├── uploads/ # 上传文件存放目录 ├── app.js # Express应用入口 └── .env # 环境变量（不入库）

添加全局中间件时的顺序很有讲究。我的习惯顺序是：日志 → 静态资源 → 解析请求体 → 跨域处理 → 路由 → 404处理 → 错误处理。特别是错误处理中间件必须在路由之后注册，否则错误会被前置逻辑拦截。

// app.js核心骨架 const express = require('express'); const cors = require('cors'); const app = express(); app.use(express.json()); app.use(express.urlencoded({ extended: true })); app.use(cors()); // 开发阶段放开跨域 app.use('/uploads', express.static('uploads')); // 静态图片访问 // 业务路由 app.use('/api/auth', authRoutes); app.use('/api/products', productRoutes); app.use('/api/favorites', favoriteRoutes); // 404兜底 app.use((req, res) => res.status(404).json({ code: 404, message: '接口不存在' })); // 统一错误处理 app.use((err, req, res, next) => { console.error(err.stack); res.status(err.status || 500).json({ code: err.status || 500, message: err.message }); }); const PORT = process.env.PORT || 3000; app.listen(PORT, () => console.log(`Server running on port ${PORT}`));

4.2 文件上传与图片处理技术

二手物品交易，商品图片是灵魂。买家看不到实物，图片的质量直接决定成交率。这一块要处理的技术点比想象中多。

我选型multer作为上传中间件，配合本地磁盘存储。很多人会纠结要不要上OSS云存储，我建议是：课程设计或中小项目阶段，老老实实存本地就行。云存储要配密钥、配绑定域名、配上传凭证，折腾一圈对核心业务毫无帮助，本地uploads目录加静态托管已经完全满足需求。

上传路由的核心逻辑：

const multer = require('multer'); const path = require('path'); const storage = multer.diskStorage({ destination: (req, file, cb) => cb(null, 'uploads/'), filename: (req, file, cb) => { // 用时间戳+随机数生成文件名，避免中文名和重复名 const uniqueName = Date.now() + '-' + Math.round(Math.random() * 1e9); const ext = path.extname(file.originalname); cb(null, uniqueName + ext); } }); const upload = multer({ storage, limits: { fileSize: 5 * 1024 * 1024 }, // 单文件5MB上限 fileFilter: (req, file, cb) => { const allowTypes = ['.jpg', '.jpeg', '.png', '.webp', '.gif']; const ext = path.extname(file.originalname).toLowerCase(); if (allowTypes.includes(ext)) cb(null, true); else cb(new Error('只支持jpg/png/webp/gif格式')); } }); // 商品发布接口，一次性最多传5张图 app.post('/api/products', authMiddleware, upload.array('images', 5), productController.create);

这里有两个我踩过的坑值得单独说：

第一，multer的fileFilter里如果调用cb(new Error())，错误不会自动送到全局错误处理中间件，而是会直接传给路由的回调函数。所以必须在路由层再包一层try-catch，否则用户传了非法格式文件时，前端收到的不是友好的JSON错误，而是Express默认的HTML错误页。

第二，图片删除问题。用户删除商品时，对应的图片文件还留在服务器上，时间长了uploads目录会越来越大。用fs.unlink同步清理即可，但要注意路径拼接：

const fs = require('fs'); const path = require('path'); // 删除商品时同时清理图片 fs.unlink(path.join(__dirname, '../uploads', imageName), (err) => { if (err) console.warn('图片删除失败:', err.message); // 文件不存在不用报错，下次定时任务统一清理 });

4.3 搜索与筛选的组合查询

二手平台上搜索是核心入口。如果用户没法快速找到想要的物品，平台的流转效率会大打折扣。Sequelize做组合查询的思路比较清晰，用Op操作符动态拼接查询条件：

const { Op } = require('sequelize'); async function getProductList(req, res) { const { keyword, category, minPrice, maxPrice, page = 1, pageSize = 12, sort = 'new' } = req.query; const where = { status: 0 }; // 只查在售商品 // 关键字模糊搜索：匹配标题或描述 if (keyword) { where[Op.or] = [ { title: { [Op.like]: `%${keyword}%` } }, { description: { [Op.like]: `%${keyword}%` } } ]; } // 分类筛选 if (category) where.category = category; // 价格区间筛选 if (minPrice || maxPrice) { where.price = {}; if (minPrice) where.price[Op.gte] = minPrice; if (maxPrice) where.price[Op.lte] = maxPrice; } // 排序：最新发布 const order = sort === 'old' ? ['created_at', 'ASC'] : ['created_at', 'DESC']; // 分页查询 const { count, rows } = await Product.findAndCountAll({ where, order, limit: pageSize, offset: (page - 1) * pageSize, include: [{ model: User, attributes: ['id', 'nickname', 'avatar'] }] }); res.json({ code: 0, data: { list: rows, total: count, page, pageSize } }); }

搜索建议直接用LIKE '%keyword%'，这个场景并发量不大，不需要上Elasticsearch这种重型方案，MySQL的模糊查询足够。价格区间用Op.gte和Op.lte（即大于等于、小于等于）不容易出现边界遗漏。

分页参数建议做一个统一的参数校验，防止用户传入page=-1或pageSize=9999这种非法值把服务拖垮：

const safePage = Math.max(1, parseInt(page) || 1); const safePageSize = Math.min(50, parseInt(pageSize) || 12);

4.4 实时聊天功能的Socket.IO实现

前面提到"共享"和"互动"属性，聊天功能是增强交互体验的加分项。教材项目往往只有留言区，但现实中买家更倾向于私下沟通价格和交易细节。引入socket.io做实时消息推送，能让平台完整度上一个档次。

接入思路：

const http = require('http'); const { Server } = require('socket.io'); const server = http.createServer(app); const io = new Server(server, { cors: { origin: '*' } }); // 在线用户映射：userId -> socketId const onlineUsers = new Map(); io.use((socket, next) => { const token = socket.handshake.auth.token; try { const user = jwt.verify(token, process.env.JWT_SECRET); socket.user = user; next(); } catch (err) { next(new Error('认证失败')); } }); io.on('connection', (socket) => { onlineUsers.set(socket.user.id, socket.id); socket.on('private-message', async (data) => { // 存库 + 转发给在线接收方 const targetSocketId = onlineUsers.get(data.toUserId); if (targetSocketId) { io.to(targetSocketId).emit('private-message', { from: socket.user.id, content: data.content, timestamp: Date.now() }); } }); socket.on('disconnect', () => { onlineUsers.delete(socket.user.id); }); }); server.listen(PORT);

这里要注意的是不要把实时消息系统做得过于复杂，支持在线私聊+消息落库就足够了。离线消息可以不做推送，等对方上线后拉取未读消息列表就行，毕竟校园场景下用户在线时间比较集中。

4.5 管理后台与统计功能

除了用户端，管理员视角也是平台完整性的体现，你需要有一个基础的管理后台入口。管理员具备的能力至少包括：

• 商品审核：下架违规或虚假商品
• 用户管理：封禁恶意用户
• 数据统计：商品总量、分类分布、活跃用户数

用一个简单的中间件实现管理员权限校验：

const requireAdmin = (req, res, next) => { if (req.user?.role !== 1) { return res.status(403).json({ code: 403, message: '无管理员权限' }); } next(); }; app.get('/api/admin/stats', authMiddleware, requireAdmin, adminController.getStats);

统计接口的SQL聚合逻辑值得分享一下。分类分布只要一条GROUP BY：

SELECT category, COUNT(*) AS count FROM products WHERE status = 0 GROUP BY category;

活跃用户数可以定义为一个时间段内发布过商品或发送过消息的用户数，用COUNT(DISTINCT user_id)避免重复计数。

5. 前端联调与项目部署上线

到这个阶段，技术骨架基本搭完了，前端的实现细节、联调流程和部署方案是决定项目能否真正跑通的关键。

5.1 前端页面结构与路由设计

前端我用Vue 3 + Vite + Element Plus组合，这已经是目前中小型项目的高效标配。

页面结构规划成6个核心视图：

• 首页：商品瀑布流列表，搜索栏 + 分类导航
• 商品详情页：轮播图、价格、描述、发布者信息、留言列表
• 发布页：表单 + 多图上传 + 价格输入
• 个人中心：我发布的、我收藏的、我买到的、个人信息编辑
• 登录/注册页：表单验证 + 跳转逻辑
• 管理后台：数据概览 + 商品管理 + 用户管理

路由设计上建议把嵌套关系和懒加载同时做好：

// router/index.js const routes = [ { path: '/', component: () => import('../views/Home.vue'), meta: { title: '首页' } }, { path: '/product/:id', component: () => import('../views/ProductDetail.vue') }, { path: '/publish', component: () => import('../views/Publish.vue'), meta: { requiresAuth: true } }, { path: '/profile', component: () => import('../views/Profile.vue'), meta: { requiresAuth: true } }, { path: '/admin', component: () => import('../views/Admin.vue'), meta: { requiresAuth: true, requiresAdmin: true } }, { path: '/login', component: () => import('../views/Login.vue') } ];

requireAuth和requiresAdmin通过全局前置守卫动态校验：

router.beforeEach((to) => { const token = localStorage.getItem('token'); if (to.meta.requiresAuth && !token) { return { path: '/login', query: { redirect: to.fullPath } }; } if (to.meta.requiresAdmin) { const role = JSON.parse(localStorage.getItem('user') || '{}').role; if (role !== 1) return { path: '/' }; } });

还有个细节容易被忽略——路由懒加载。把每个页面组件用() => import()包裹，首屏加载只拉必要的JS chunk，切换页面时才按需加载，体验会顺畅很多。

5.2 axios封装与Token携带策略

整个前端与后端交互的核心是axios实例的封装。我习惯封装一个request.js，统一处理：

import axios from 'axios'; import { ElMessage } from 'element-plus'; const request = axios.create({ baseURL: '/api', // 开发环境走Vite代理 timeout: 10000 }); // 请求拦截器：自动携带token request.interceptors.request.use((config) => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); // 响应拦截器：统一处理错误码 request.interceptors.response.use( (response) => { return response.data; }, (error) => { if (error.response?.status === 401) { localStorage.removeItem('token'); localStorage.removeItem('user'); window.location.href = '/login'; ElMessage.error('登录已过期，请重新登录'); } else { const msg = error.response?.data?.message || '网络异常'; ElMessage.error(msg); } return Promise.reject(error); } );

这里的最佳实践是把错误提示统一在拦截器里弹出，页面代码里就不用每个请求都catch一遍了。401状态码（token过期或无效）做全局登出处理，直接从根上解决"登录态失效后各个页面到处跳错"的问题。

开发环境的跨域问题，不用在后端CORS配置上反复折腾，直接在Vite配置里代理转发：

// vite.config.js export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:3000', changeOrigin: true } } } });

这样前端的请求路径写成/api/products，实际由Vite转发到后端的http://localhost:3000/api/products，浏览器层面完全感知不到跨域，省心很多。

5.3 Vue中使用富文本与图片上传组件

商品描述如果只给一个纯文本框，体验会比较单调。Element Plus自带的el-input @type="textarea"足够完成基本需求，但如果想更专业，我推荐搭配v-md-editor之类的Markdown编辑器组件，或者干脆实现一个"图片上传区 + 纯文本描述"的组合模块。

图片上传组件最好复用，封装成一个ImageUploader.vue：

<template> <div class="uploader"> <div v-for="(img, index) in modelValue" :key="index" class="img-item"> <img :src="img" alt="商品图" /> <span class="remove" @click="handleRemove(index)">删除</span> </div> <div v-if="modelValue.length < maxCount" class="upload-btn" @click="selectFile"> 选择图片 </div> <input ref="fileInput" type="file" accept="image/*" multiple style="display:none" @change="handleChange" /> </div> </template> <script setup> import { ref } from 'vue'; import { ElMessage } from 'element-plus'; import request from '../utils/request'; const props = defineProps({ modelValue: { type: Array, default: () => [] }, maxCount: { type: Number, default: 5 } }); const emit = defineEmits(['update:modelValue']); const fileInput = ref(null); const selectFile = () => fileInput.value.click(); const handleChange = async (e) => { const files = Array.from(e.target.files); for (const file of files) { const formData = new FormData(); formData.append('image', file); try { const res = await request.post('/upload', formData); emit('update:modelValue', [...props.modelValue, res.data.url]); } catch (err) { ElMessage.error('上传失败'); } } e.target.value = ''; }; </script>

这个组件把上传逻辑完全封装，任何页面（发布页、个人资料头像上传）直接引入使用即可。组件始终以modelValue数组的形式与外层交互，符合Vue双向绑定的使用习惯。

5.4 部署方案与pm2进程管理

部署是整个项目从开发走向可用的最后一公里。我给出一套可复制到任何Linux云服务器（Ubuntu 20.04或CentOS 7+）的部署方案。

后端部署，核心就是三样东西：Node运行时、PM2进程管理器和Nginx反向代理。

在服务器上安装Node：

# 使用NodeSource源安装Node 18 curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash - sudo apt-get install -y nodejs

PM2是Node.js进程守护神器，让应用在后台常驻、崩溃自动重启：

npm install -g pm2 # 启动应用 pm2 start app.js --name second-hand-platform # 保存当前进程列表，设置开机自启 pm2 save pm2 startup

PM2的常用管理命令值得提交掌握：

pm2 logs second-hand-platform # 查看实时日志 pm2 restart second-hand-platform # 重启 pm2 status # 查看进程状态 pm2 monit # 实时监控CPU和内存

前端部署，构建后交给Nginx托管：

# 构建后生成dist目录 npm run build # Nginx配置 server { listen 80; server_name your-domain.com; # 静态资源 root /var/www/second-hand-platform/dist; index index.html; # 解决Vue history模式刷新404问题 location / { try_files $uri $uri/ /index.html; } # 反向代理后端API location /api/ { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 图片上传文件访问 location /uploads/ { proxy_pass http://127.0.0.1:3000; } }

try_files $uri $uri/ /index.html;这一行是history路由模式的关键配置。如果少了它，用户在/product/123这种路径下刷新页面，Nginx会去找/product/123这个文件然后返回404。

环境变量在部署时也要同步配置好。.env文件要包含：

PORT=3000 JWT_SECRET=你的自定义密钥，越长越好 DB_HOST=127.0.0.1 DB_NAME=second_hand DB_USER=root DB_PASSWORD=数据库密码

生产环境务必不要在JWT_SECRET里用简单值或者默认值。密钥泄露意味着任何人都能伪造登录token，后果很严重。

6. 高频问题速查与避坑总结

开发过程中我实际踩过的坑，整理成速查表供参考，每一条都对应一个真实场景：

还有一个容易被忽视的安全隐患需要重点提醒：文件上传接口如果没有做类型校验，可以被人直接上传一个.js或.html文件到服务器上，结合静态托管，构成存储型XSS攻击。multer的fileFilter只能拦住一部分，更稳妥的做法是：

1. 上传时用path.extname()校验扩展名白名单
2. 保存文件名重新生成，保留原文件名中的扩展名但过滤掉特殊字符
3. 静态托管的uploads目录禁止执行脚本

Nginx下可以这样配置加固：

location /uploads/ { proxy_pass http://127.0.0.1:3000; location ~* \.(php|php5|asp|aspx|jsp|py|sh|js)$ { deny all; } }

数据备份也建议养成习惯。校园平台虽然数据量不大，但一旦服务器出问题，所有用户记录和交易数据全没，连排查的余地都没有。写个简单脚本每天凌晨用mysqldump导出：

#!/bin/bash mysqldump -u root -p你的密码 second_hand > /backup/second_hand_$(date +%Y%m%d).sql find /backup -name "*.sql" -mtime +7 -delete

配合crontab每天执行一次，数据安全就有了基本保障。

从环境搭建到功能开发再到部署上线，整个项目链条中的每一个环节，我都尽量把踩过的坑和绕过弯路的经验写在上面。这个项目做下来最大的体会是：校园二手平台的技术难点其实不在Node.js本身，而在于业务逻辑的完整性和细节的严谨性。一个是商品状态流转不能乱，一个是文件生命周期要管好，一个是安全底线要守住。做到这三点，项目就已经能站得住脚了。剩下加不加Redis缓存、要不要做推荐算法，都是锦上添花，先把地基打牢才是关键。