做毕设或者练手项目的时候，很多人一看到"管理系统"四个字，第一反应就是"图书管理""仓库管理""班级管理"那老几样——说好听点是经典，说难听点是答辩老师已经看吐了。如果你本身追星，又想把爱好和项目结合，那"基于微信小程序实现追星管理系统"这个题目就非常有意思：它既有完整的业务闭环（用户、内容、活动、日程），又有足够的技术纵深（登录鉴权、动态feed流、日历组件、并发报名），更重要的是它提供了一个真实的使用场景，而不是为了管理系统而管理系统。
这篇文章我把整个项目的落地过程拆开讲清楚：从功能边界怎么定、技术栈怎么选、数据库怎么建模，到核心功能的代码链路怎么走、小程序开发里那些坑怎么绕，最后再讲讲配套的论文和源码应该怎么组织。内容偏实操，适合准备毕业设计、课程设计，或者想完整跟一个全栈小程序项目的同学。项目源码和论文说明我放在最后统一说组织方式，先看技术部分。
1. 从追星的真实需求出发：这系统不是信息展示工具
很多人在做这类项目的时候，容易把"追星管理系统"理解成一个明星资讯App——放几张照片、列几个作品、写一段简介，完了。这其实是最大的误区。你回去看题目里的关键词："管理系统"。管理的是什么？不是明星的资料，而是粉丝围绕追星这件事产生的行为数据。系统的主角是"用户"和"用户的行为"，不是"明星"。
1.1 三个典型场景定下系统边界
我在设计功能之前，先模拟了三个真实的追星场景：
场景一：日常逛资讯。用户打开小程序，看到关注明星的最新动态（行程官宣、新歌发布、综艺录制），可以点赞、评论，也可以把明星加入关注列表。这个场景对应的是内容feed流和关注机制。
场景二：组织应援活动。某位粉丝想给偶像组织一次生日应援，在系统里发起一个活动，填写时间、地点、应援形式、筹款目标，其他粉丝看到后报名参与。这个场景对应的是应援活动的发布、报名和进度管理。
场景三：管理追星行程。用户把近期要去的演唱会、粉丝见面会、机场接送机安排记在系统里，形成个人行程日历，避免错过关键时间点。这个场景对应的是日程日历和打卡管理。
这三个场景一摆出来，系统的边界就清楚了：需要C端（小程序用户端）和B端（管理后台），需要内容、活动、日程三条主线，还需要用户体系贯穿始终。如果你只做一个明星展示页，后面所有的数据模型和接口设计都撑不起来，论文也没法写。
1.2 功能模块拆解：从明星档案到应援组织
我最终把系统拆成了六个功能模块：
| 模块 | 核心功能 | 对应场景 |
|---|---|---|
| 用户模块 | 微信授权登录、个人资料、关注列表 | 所有场景的基础 |
| 明星模块 | 明星档案、代表作品、粉丝排行 | 场景一 |
| 动态社区 | 发布动态、点赞、评论、feed流 | 场景一 |
| 日程模块 | 明星行程日历、个人行程安排、打卡 | 场景三 |
| 应援模块 | 活动发布、活动列表、报名参与、进度展示 | 场景二 |
| 个人中心 | 我的关注、我的报名、我的打卡、数据看板 | 三个场景的聚合 |
管理后台我是单独做的，技术上可以用小程序端的"管理员角色"实现，也可以做一个独立的Web管理端。考虑到毕设的工作量，我建议管理后台先用小程序内的隐藏入口实现，用角色字段区分普通用户和管理员，管理员可以审核动态、管理明星档案、处理应援活动。这样一套代码搞定两端，论文里也能说"系统包含用户端与管理员端"。
提示：功能划分不是越多越好。模块一旦超过六个，开发周期和论文篇幅都会失控。抓住"内容、日程、应援"三条线，其他都是锦上添花。
2. 技术选型复盘：微信小程序、uni-app与后端框架怎么配
既然是"基于微信小程序实现"，前端的主体技术栈基本是确定的。但这里有一个前置问题：用原生小程序还是用uni-app？后端又该选什么？这两个决定一旦做错，后面返工的代价非常大。
2.1 为什么小程序原生开发是更稳的起点
我做这个项目用的是微信小程序原生开发（WXML + WXSS + JavaScript），没有引入uni-app。原因很简单：这是一个以"完成项目和论文"为目标的系统，不是以"跨多端上架"为目标的商业产品。
原生开发的好处体现在三个地方：
- 调试链路最短。微信开发者工具直接编译预览，真机调试一键到位，不需要经过uni-app的编译层。遇到样式问题可以直接在WXSS里定位。
- API覆盖最全。微信小程序的登录、支付、订阅消息、获取头像昵称等能力，原生框架永远是最先支持的。uni-app虽然有条件编译，但遇到平台差异时还是要写原生代码。
- 论文更好写。"基于微信小程序原生框架开发"这句话在论文里本身就是一句明确的架构描述，而uni-app的写法反而要额外解释"为什么不用原生"。
当然，如果你以后想同时出App和H5，uni-app是更好的选择。但就这个项目而言，原生开发付出的成本更低，踩坑更少。我在第5章会专门讲讲原生开发里那些文档上不会写的坑。
2.2 后端选型：Node.js、Spring Boot还是PHP
后端的选择直接决定你写论文时"技术介绍"这一章有没有内容可写。这个项目常见的选择有三种：
- Node.js + Express/Koa + MySQL：学习曲线平缓，JavaScript前后端同构，关键代码量最少。我自己用的就是这个组合，适合前端基础好、想快速出活的人。
- Java Spring Boot + MyBatis-Plus + MySQL：如果你所在的学校对毕设的技术要求偏"企业级"，Spring Boot是加分项，但代码量和环境配置复杂度都会上升。
- PHP + ThinkPHP + MySQL：老牌组合，网上资料多，部署简单（装个phpStudy就行），但论文里技术亮点相对一般。
这里我多说一句：如果你实在不想写后端，可以走微信云开发路线，用云函数 + 云数据库，省掉服务器部署和域名备案。但代价是论文里"系统设计"的篇幅会缩水，答辩老师追问接口怎么设计的时候会比较吃力。我的建议是：以毕设拿学位为目标选传统后端，以快速上线体验为目的选云开发。
2.3 项目目录规划与开发环境准备
一个清晰的项目结构能让你少走很多弯路。我的目录是这样分的：
miniprogram/ # 小程序前端 ├── pages/ # 页面 │ ├── index/ # 首页动态feed流 │ ├── star/ # 明星列表与详情 │ ├── schedule/ # 行程日历 │ ├── activity/ # 应援活动 │ ├── user/ # 个人中心 │ └── login/ # 登录页 ├── components/ # 自定义组件（日历、动态卡片等） ├── utils/ # 请求封装、日期工具、常量 ├── app.js # 全局逻辑，登录状态管理 ├── app.json # 页面注册与tabBar配置 └── app.wxss # 全局样式 server/ # Node.js后端 ├── routes/ # 路由 ├── controllers/ # 控制器 ├── services/ # 业务逻辑 ├── models/ # 数据模型（Sequelize） └── app.js # 服务入口 docs/ # 论文与设计文档开发环境的准备没什么特殊的：微信开发者工具装最新稳定版、Node.js 16以上、MySQL 5.7或8.0、Navicat或DBeaver管数据库。唯一要注意的是后端接口必须在小程序后台配置request合法域名，开发阶段勾选"不校验合法域名"，上线前必须换成已备案的HTTPS域名。
3. 核心数据建模：一套表结构撑起追星全流程
数据模型是这类系统的骨架，也是论文里最出彩的部分。我把表分成两组：基础档案和行为数据。基础档案回答"有哪些对象"，行为数据回答"用户对对象做了什么"。
3.1 基础档案：用户、明星、作品三张表
用户表（user）存的是微信登录后沉淀下来的用户身份和基础信息：
CREATE TABLE `user` ( `id` bigint NOT NULL AUTO_INCREMENT, `openid` varchar(64) NOT NULL COMMENT '微信openid，唯一标识', `nickname` varchar(64) DEFAULT '' COMMENT '昵称', `avatar` varchar(255) DEFAULT '' COMMENT '头像URL', `role` tinyint DEFAULT 0 COMMENT '0-普通用户 1-管理员', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_openid` (`openid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;注意两点：一是openid必须有唯一索引，因为微信登录的核心就是拿openid找老用户；二是角色字段提前预留，后面做管理后台入口就靠它区分。
明星表（star）存的是明星的基础档案，字段不多，但要注意把"粉丝数""关注量"这种高频统计字段冗余在表里，避免每次都去count：
CREATE TABLE `star` ( `id` bigint NOT NULL AUTO_INCREMENT, `name` varchar(64) NOT NULL, `alias` varchar(64) DEFAULT '' COMMENT '艺名/别名', `avatar` varchar(255) DEFAULT '', `birthday` date DEFAULT NULL, `agency` varchar(128) DEFAULT '' COMMENT '经纪公司', `intro` text COMMENT '简介', `fans_count` bigint DEFAULT 0 COMMENT '粉丝数（冗余统计）', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;作品表（work）比较简单，关联明星id，存作品名称、类型（音乐/影视/综艺）、发布时间、封面图。一张作品表就够了，不需要再拆出"专辑表"和"影视表"，那是过度设计。
3.2 行为数据：日程、应援、打卡、收藏四类表
日程表（schedule）是明星行程，前端日历靠它渲染：
CREATE TABLE `schedule` ( `id` bigint NOT NULL AUTO_INCREMENT, `star_id` bigint NOT NULL, `type` tinyint NOT NULL COMMENT '1-演唱会 2-见面会 3-综艺录制 4-其他', `title` varchar(128) NOT NULL, `location` varchar(255) DEFAULT '', `start_time` datetime NOT NULL, `end_time` datetime DEFAULT NULL, `status` tinyint DEFAULT 0 COMMENT '0-未开始 1-进行中 2-已结束', PRIMARY KEY (`id`), KEY `idx_star_time` (`star_id`, `start_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;应援活动表（support_activity）是这个系统业务最重的一张表：
CREATE TABLE `support_activity` ( `id` bigint NOT NULL AUTO_INCREMENT, `star_id` bigint NOT NULL, `organizer_id` bigint NOT NULL COMMENT '发起人用户id', `title` varchar(128) NOT NULL, `description` text, `type` tinyint DEFAULT 0 COMMENT '0-生日应援 1-公益应援 2-线下应援 3-其他', `target_count` int DEFAULT 0 COMMENT '目标参与人数', `current_count` int DEFAULT 0 COMMENT '当前参与人数', `location` varchar(255) DEFAULT '', `start_time` datetime NOT NULL, `end_time` datetime DEFAULT NULL, `status` tinyint DEFAULT 0 COMMENT '0-报名中 1-进行中 2-已结束', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_star_status` (`star_id`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;current_count这个字段很关键，后面实现报名并发控制的时候就是靠它。
报名表（activity_signup）把应援活动和用户关联起来，同时记录报名时间和留言。
打卡表（check_in）是"日程管理"和"行为激励"的结合。用户可以在某个明星的行程页面打卡，记录"今天也在追星"。打卡表用 user_id + star_id + date 做联合唯一索引，防止一天重复打卡。
收藏表（favorite）和评论表（comment）属于通用设计：收藏表关联用户和明星，评论表关联动态和用户。它们在论文里用来体现"一对多"和"多对多"关系，ER图上很好看。
3.3 接口设计约定：统一返回结构
建完表之后，接口风格要提前约定。我用的是RESTful风格，统一返回结构：
{ "code": 0, "msg": "success", "data": { } }- code = 0 表示成功，非0表示业务错误（比如1001表示未登录，1002表示参数错误，1003表示报名人数已满）。
- 小程序端的请求封装统一判断code，不等于0就wx.showToast弹提示。
这套约定写进论文的"接口设计"小节非常直观。所有接口按资源组织：/api/stars、/api/schedules、/api/activities、/api/posts，子资源用嵌套路径，比如/api/activities/{id}/signup表示报名。
4. 关键功能实现链路：从登录到应援报名的代码级拆解
功能实现是项目的重头戏。我会挑四条主线来讲：登录鉴权、feed流、行程日历、应援报名。这四条线基本覆盖了"用户核心闭环 + 高难度技术点"，也是论文里"系统实现"章节的骨架。
4.1 微信登录鉴权：openid换了token之后
微信小程序登录的标准流程是小程序端调用wx.login拿code，把code发给后端，后端用code向微信服务端换openid和session_key，然后后端自己签发登录态token。
小程序端封装一个login函数：
// utils/auth.js function login() { return new Promise((resolve, reject) => { wx.login({ success: async (res) => { try { const resp = await request.post('/api/auth/login', { code: res.code }) if (resp.code === 0) { wx.setStorageSync('token', resp.data.token) wx.setStorageSync('userInfo', resp.data.userInfo) resolve(resp.data) } else { reject(new Error(resp.msg)) } } catch (err) { reject(err) } }, fail: reject }) }) }后端Node.js这边用axios调微信官方接口：
// controllers/authController.js const axios = require('axios'); const jwt = require('jsonwebtoken'); exports.login = async (ctx) => { const { code } = ctx.request.body; const url = 'https://api.weixin.qq.com/sns/jscode2session'; const params = { appid: '你的AppID', secret: '你的AppSecret', js_code: code, grant_type: 'authorization_code' }; const { data } = await axios.get(url, { params }); // data.openid, data.session_key if (!data.openid) { ctx.body = { code: 1002, msg: '微信登录失败' }; return; } let user = await UserModel.findByOpenid(data.openid); if (!user) { user = await UserModel.create({ openid: data.openid }); } const token = jwt.sign({ userId: user.id }, 'your_secret_key', { expiresIn: '7d' }); ctx.body = { code: 0, msg: 'success', data: { token, userInfo: user } }; };这里有三个必须注意的点：
- session_key绝不能返回给前端。那是微信会话密钥，只应该留在后端。你要是返回了，答辩老师问起来很难解释。
- 后续请求都带token。小程序端在
wx.request的header里加Authorization: Bearer ${token}，后端写一个中间件统一解析token、校验有效性、把userId挂到请求上下文上。这个中间件是整个后端安全性的基础。 - 登录是静默的，资料的完善靠用户主动填写。小程序2019年之后不再支持直接弹窗获取用户昵称头像，现在标准做法是登录后引导用户去个人中心，用
button open-type="chooseAvatar"和input type="nickname"分别获取头像和昵称。这一步在论文里可以单独写一个小节，展示你对平台规范的理解。
4.2 首页动态feed流与服务端分页
首页是动态feed流，展示所有用户发布的追星动态。feed流的实现重点在服务端分页和列表项的性能。
接口设计：
GET /api/posts?page=1&pageSize=10后端返回：
{ "code": 0, "msg": "success", "data": { "list": [ { "id": 1001, "content": "今天去看了演唱会，现场太震撼了！", "images": [...], "likeCount": 328, "commentCount": 26, "starName": "某歌手", "nickname": "追星小助手", "createTime": "2025-01-10 20:30:00" } ], "total": 156, "page": 1, "pageSize": 10, "hasMore": true } }小程序端在onReachBottom里判断hasMore再请求下一页，把新数据追加到当前list：
// pages/index/index.js onReachBottom() { if (!this.data.hasMore) return; this.setData({ loadingMore: true }); this.fetchPosts(this.data.page + 1); } async fetchPosts(page) { const resp = await request.get('/api/posts', { page, pageSize: 10 }); this.setData({ posts: this.data.posts.concat(resp.data.list), page: resp.data.page, hasMore: resp.data.hasMore }); }这里要注意一个SQL层面的设计：动态列表的联表查询一定只查需要的字段，不要SELECT *。比如列表项只需要nickname和avatar，就不要把user整行拉出来。列表接口性能是压测和论文测试章节的重要数据来源，写测试报告的时候你能拿出"接口平均响应低于200ms"这种数据，会很加分。
首页feed流还有一个体验细节：第一页数据要展示明星的名字和动态里提到的明星。最简单的做法是在post表里加star_id字段，发动态时让用户选择关联的明星，列表页直接拿star信息渲染，不需要复杂的文本识别。
4.3 明星行程日历：日期组件的二次开发
行程日历是这个小程序里视觉上最抓眼球的功能，也是技术上一个"组件二开"的好例子。小程序官方没有现成的日历组件，所以我的做法是基于scroll-view + 日期计算自己封装了一个。
核心逻辑在获取"某年某月每一天的星期分布"：
// utils/date.js function getMonthDays(year, month, cellHeight) { const firstDay = new Date(year, month - 1, 1); const startWeekday = firstDay.getDay(); // 0-6 const daysInMonth = new Date(year, month, 0).getDate(); const cells = []; // 补齐前导空格 for (let i = 0; i < startWeekday; i++) { cells.push({ day: '', disabled: true, height: cellHeight }); } // 填充真实日期 for (let d = 1; d <= daysInMonth; d++) { cells.push({ day: d, disabled: false, height: cellHeight, hasSchedule: false }); } return cells; }渲染完成后，再拿这个月的start_time范围去查数据库：
SELECT DATE(start_time) AS schedule_date, COUNT(*) AS cnt FROM schedule WHERE star_id = ? AND start_time >= '2025-01-01 00:00:00' AND start_time < '2025-02-01 00:00:00' GROUP BY DATE(start_time);把返回的日期数组传到前端，前端在日历组件里标记hasSchedule的日期，显示一个小圆点。点击有行程的日期，下方列表展示当天的具体行程。这里有个性能细节：月份切换时只请求当月的行程聚合数据，而不是一次性拉全量，不然一年下来几千条数据前端会卡。
4.4 应援活动报名：事务与并发扣减
应援模块是业务逻辑最重的地方。用户点"报名"之后，后端要做三件事：
- 检查活动是否处于"报名中"状态；
- 检查该用户是否已经报名（去重）；
- 把活动的current_count加1；
- 写入报名记录。
第3步看起来简单，但并发场景下会出大问题。如果两个用户同时报名，都读到current_count=99，然后都加1，最后变成100而不是101。解决方式是用原子更新的行锁：
// services/supportActivityService.js async signup(activityId, userId) { // 1. 检查活动状态和是否已报名 const activity = await ActivityModel.findByPk(activityId); if (!activity || activity.status !== 0) { return { code: 1003, msg: '活动不在报名期' }; } const exist = await SignupModel.findOne({ where: { activityId, userId } }); if (exist) { return { code: 1004, msg: '您已报名该活动' }; } // 2. 原子更新参与人数，影响行数=1才说明报名成功 const [affectedRows] = await ActivityModel.update( { current_count: sequelize.literal('current_count + 1') }, { where: { id: activityId, status: 0, current_count: { [Op.lt]: sequelize.col('target_count') } } } ); if (affectedRows === 0) { return { code: 1005, msg: '报名人数已满' }; } // 3. 写入报名记录 await SignupModel.create({ activityId, userId }); return { code: 0, msg: 'success' }; }这个current_count < target_count的条件原子判断非常关键：它保证了人数满了之后，后续的报名请求一定失败。整个过程因为三个操作都在同一个请求里，用事务包起来就万无一失。这块代码放进论文"系统实现"章节，既说明了你理解并发问题，又展示了解决手段，属于答辩加分项。
5. 小程序端真实开发避坑记录
这一章的价值在于，这些坑你不在真实项目里踩一遍，看文档是看不出来的。我把它写下来，希望你不用跟我一样用一个通宵来换。
5.1 自定义导航栏的适配问题
如果你的页面像我的首页一样用了自定义导航栏（为了在顶部放搜索框和明星推荐位），那一定会遇到状态栏高度和胶囊按钮位置的适配问题。不同机型的状态栏高度不一样，iPhone X以上的刘海高度和普通全面屏完全不同。
获取安全区域的标准姿势：
// app.js 或页面onLoad里 const menuButton = wx.getMenuButtonBoundingClientRect(); const systemInfo = wx.getWindowInfo(); const statusBarHeight = systemInfo.statusBarHeight; const navBarHeight = (menuButton.top - statusBarHeight) * 2 + menuButton.height;拿到这两个值之后，把自定义导航栏的高度设成statusBarHeight + navBarHeight，内容从导航栏底部开始排。如果你用了wx.getSystemInfoSync，注意新版微信里这个方法已经被wx.getWindowInfo替代了，旧方法在部分机型上拿到的状态栏高度会不准。
5.2 setData的性能陷阱与批量更新
小程序性能优化的核心就是setData，因为它会触发视图层更新。新手最容易犯的错是在循环里反复setData：
// 错误写法：循环内setData，性能极差 for (let i = 0; i < list.length; i++) { this.setData({ [`items[${i}]`]: list[i] }); } // 正确写法：先拼好整个对象，一次setData const items = list.map(item => ({ ...item, formatted: formatTime(item.time) })); this.setData({ items });一个页面同时更新多个数据字段时，把要改的字段合成一个对象再setData。另外，不要往data里塞大文本和图片的base64。我最早把动态内容的完整HTML直接塞进data，页面卡成PPT。后来改成只存纯文本摘要和图片URL列表，渲染速度快了一个量级。
5.3 iOS日期解析的经典坑
iOS的JavaScript解析new Date('2025-01-10 20:30:00')会直接解析失败，返回Invalid Date，因为iOS不支持字符串中间的横线和空格这个格式组合。Android没这个问题，所以你在安卓机上测得好好的，一上iPhone就白屏或者显示NaN。
标准解法是把日期字符串的横线替换成斜杠：
function parseDate(dateStr) { return new Date(dateStr.replace(/-/g, '/')); }所有从后端返回的时间字段，只要需要在前端做getHours()、getMonth()这类操作，先过一遍这个函数。这个坑我建议你在论文的"运行环境与兼容性"小节里也提一句，说明你做过真机兼容性测试。
5.4 图片上传与临时文件路径过期
wx.chooseMedia选出来的图片路径是wxfile://临时路径，只在本次会话内有效，刷新页面之后大概率失效。正确的流程是选择图片后立刻上传到服务器，用服务器返回的URL来展示。
上传的核心逻辑很简单：
wx.chooseMedia({ count: 9, mediaType: ['image'], success: (res) => { res.tempFiles.forEach((file, index) => { wx.uploadFile({ url: 'https://api.example.com/api/upload', filePath: file.tempFilePath, name: 'file', success: (uploadRes) => { const data = JSON.parse(uploadRes.data); uploadedUrls.push(data.data.url); } }); }); } });后端用multer接收文件，存到服务器静态目录或对象存储（OSS），返回可访问的URL。记住一个原则：前端永远不要持久化保存本地临时路径，数据库里只存服务器URL。
5.5 审核与合规注意事项
小程序上线前要过微信审核。这个项目的几个合规点，我在被拒了两次之后才摸清楚：
- 用户发布的内容（动态、评论）一定走后端内容安全检测。微信提供了内容安全接口
msgSecCheck和mediaCheckAsync，发布接口先调用安全检测再入库。不接这些，审核容易打回。 - 虚拟支付问题。应援活动如果需要在线收款，涉及虚拟支付和资金流向，个人小程序几乎无法过审。我的处理方式是：应援活动只做报名和线下参与，交易信息一律线下沟通。这个限制要写清楚，避免审核被卡。
- 用户隐私协议。涉及到收集用户头像昵称、登录openid，必须在小程序后台配置用户隐私保护指引，并在首次启动时弹窗告知用户。
- 审核不是骗审，是合规。把规则读透，按规则来，你的项目才能稳定跑下去。走歪门邪道的人，最后不是被清退就是被提审，得不偿失。
6. 配套论文与源码组织：毕设拿高分的写作思路
项目做完只是第一步，把这个项目变成一篇能过审的论文、一套能让人看懂的源码，是另一条战线。我见过不少同学代码写得挺好，论文却写得像"用户操作手册"，最后答辩被问得支支吾吾。这里我讲一下论文和源码的组织思路。
6.1 论文五章结构的写法
本科毕设论文的标准结构基本是五章，我写这份项目论文时参考的结构是这样的：
- 第一章 绪论：背景写粉丝经济和小程序生态的快速发展（控制篇幅，别写成长篇论文综述），研究现状写"现有追星类产品多为资讯App，缺少面向粉丝个人的行程与应援管理工具"——这句定位非常重要，它是你整个项目的出发点。
- 第二章 相关技术介绍：微信小程序框架、Node.js/Spring Boot（你用的哪个写哪个）、MySQL、RESTful API、JWT鉴权。每项技术写"是什么 + 为什么用它"，两到三页就够。
- 第三章 系统需求分析：用例图（用户端和管理员端各一张）、功能需求列表、非功能需求（性能、安全、易用性）。
- 第四章 系统设计：系统架构图、功能模块图、数据库ER图、核心表结构说明、接口设计说明。
- 第五章 系统实现与测试：每个核心功能配一张小程序截图 + 一段核心逻辑说明，然后写测试用例表和测试结论（功能测试、性能测试）。测试数据就来自你自己跑项目的实测结果。
6.2 图表、用例图和ER图怎么做
论文里的图我不用特别复杂的专业工具，运plain画宽 picGo画宽就足够了。架构图、功能模块图用ProcessOn或draw.io画，数据库ER图用Navicat的逆向查询功能自动生成，导出成图片放到论文里。用例图可以直接用PlantUML写，代码就是文本，方便后期修改。
规格和截图要注意一个细节：论文里的截图要清晰、能看清字段，不要截半屏或模糊的图。所有截图统一在真机或者开发者工具里用"截图"功能保存，不要用手机对着屏幕拍照。图片统一处理成灰度或统一色系，整本论文会显得专业很多。
6.3 源码目录与README的规范
"附项目源码"不是把代码打个zip包就完了。一个拿得出手的源码包，至少包含：
追星管理系统-源码/ ├── README.md # 项目介绍、技术栈、启动步骤 ├── docs/ # 设计文档、ER图、接口文档 ├── miniprogram/ # 小程序前端 ├── server/ # 后端服务 ├── database/ # SQL初始化脚本 └── 论文说明.docx/pdf # 论文正文README是最容易被忽略但最重要的文件之一。我在README里写了这三块内容：环境要求（微信开发者工具版本、Node版本、MySQL版本）、启动步骤（初始化数据库、启动后端、导入小程序项目、修改AppID和接口地址）、账号说明（如果需要管理员账号，把初始化SQL里的默认管理员账号写清楚）。
论文说明文件里除了正文，我建议单独加一节"复现说明"，把二次开发需要注意的地方（比如替换AppSecret、配置合法域名）写进去。这样不管谁来拿你的源码，照着文档半小时内就能跑起来。答辩的时候老师让你演示系统，你现场三分钟启动成功，这个印象分很高。
最后再分享一点我做这个项目的体会。写代码是一回事，把代码背后的思考讲清楚是另一回事。技术选型时我反复纠结过前端用不用uni-app、后端用不用云开发，最后坚持了原生小程序 + Node.js + MySQL这套最"朴素"的方案，进度反而最快，论文也最好写。原因很简单，这个组合生态成熟、资料齐全，你踩的每一个坑几乎都能搜到解决方案。对于追星管理系统这样一个中型的全栈项目，最大的风险从来不是技术不够新，而是你自己被那些花哨的框架和概念拖住了手脚。先把核心链路跑通，再谈优化，这句话我每次被人问起怎么做项目都会说一遍。
