做毕设或者练手项目的时候很多人一看到管理系统四个字第一反应就是图书管理仓库管理班级管理那老几样——说好听点是经典说难听点是答辩老师已经看吐了。如果你本身追星又想把爱好和项目结合那基于微信小程序实现追星管理系统这个题目就非常有意思它既有完整的业务闭环用户、内容、活动、日程又有足够的技术纵深登录鉴权、动态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和H5uni-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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意两点一是openid必须有唯一索引因为微信登录的核心就是拿openid找老用户二是角色字段提前预留后面做管理后台入口就靠它区分。明星表star存的是明星的基础档案字段不多但要注意把粉丝数关注量这种高频统计字段冗余在表里避免每次都去countCREATE 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;作品表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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;应援活动表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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;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-typechooseAvatar和input typenickname分别获取头像和昵称。这一步在论文里可以单独写一个小节展示你对平台规范的理解。4.2 首页动态feed流与服务端分页首页是动态feed流展示所有用户发布的追星动态。feed流的实现重点在服务端分页和列表项的性能。接口设计GET /api/posts?page1pageSize10后端返回{ 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_count99然后都加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这套最朴素的方案进度反而最快论文也最好写。原因很简单这个组合生态成熟、资料齐全你踩的每一个坑几乎都能搜到解决方案。对于追星管理系统这样一个中型的全栈项目最大的风险从来不是技术不够新而是你自己被那些花哨的框架和概念拖住了手脚。先把核心链路跑通再谈优化这句话我每次被人问起怎么做项目都会说一遍。