微信小程序原创音乐管理系统：全栈开发与论文实战解析

1. 项目拆解：标题背后到底是一个什么样的系统

先把这个标题拆开看。“基于微信小程序实现原创音乐小程序管理系统”，重点词有三个：微信小程序、原创音乐、管理系统。再加后面那句“项目源码+论文说明”，基本就能判断出来，这是一套典型的毕业设计/课程设计型全栈项目，目标很明确：做一个能跑、能演示、能写进论文里的完整系统。

很多同学看到这种标题第一反应是“又是一个XXX管理系统”，觉得没新意。但说实话，音乐类小程序管理系统在毕设项目里比普通的学生管理、图书管理要高级不少，因为它的业务链路更长，涉及的技术点也更丰富。普通管理系统无非是增删改查，音乐系统则要额外处理音频文件的上传与播放、版权归属、分类榜单、收藏评论、甚至会员付费。这些业务场景堆在一起，整套系统的复杂度立刻上来了。

这个系统最终要解决什么问题？从使用者的角度去看，它其实包含两个端口：

• 普通用户（C端）：在小程序里听歌、搜索歌曲、查看歌手、收藏歌单、发表评论。
• 管理员（B端）：在后台管理页面里维护歌曲信息、歌手信息、用户状态、统计数据，处理用户反馈。

所以在做设计时，不要把它想成“一个微信小程序”，而是“一个小程序前端 + 一个后台管理端 + 一个服务端接口层 + 一个数据库”的完整前后端分离项目。这也是绝大多数毕设和商业项目的通用形态。“原创”两个字也很关键，它决定了业务上要多一个角色：独立音乐人或原创歌手。歌手能够入驻、上传自己的原创音乐，管理员审核后上架。这就把简单的点歌平台升级成了带内容生产属性的社区平台，也直接对应了系统里那些“歌手管理”“作品审核”功能模块的设计由来。

对于准备拿这个项目做毕设的同学，这套系统的好处是覆盖面广，论文和技术答辩都有东西可写：前端有微信小程序原生开发或uniapp跨端开发，后端有接口设计、鉴权、文件上传下载，数据库有表关系设计，部署有服务器和域名配置。一个项目把Web开发的核心知识点全部串起来了。

2. 系统架构设计与技术选型思路

2.1 前后端分离结构怎么划分

做这类项目，第一步不是写代码，而是先把架构定下来。我见过太多同学上来就在微信开发者工具里狂写页面，写到一半发现没有后端接口，又掉头去补后端，最后两边缝合得很痛苦。正确顺序是：先画架构图，再定接口，再分头开发。

整个系统按端来划分，比较合理的结构是这样：

• 微信小程序端：用户使用的界面，负责展示音乐列表、播放控制、登录注册、评论收藏等交互。
• 管理后台端：管理员使用的界面，Web页面，负责歌曲/歌手/用户的CRUD操作，数据统计。这部分可以用Vue或React快速搭建，也可以用更简单的HTML+模板渲染。
• 后端服务：对外提供RESTful API接口，处理业务逻辑、鉴权、文件存储与读取。
• 数据库：存储所有结构化数据，包括用户、歌曲、歌手、分类、评论、收藏、订单等。
• 对象存储：音频文件本身不适合直接放数据库，需要单独存放，比如云存储或服务器磁盘目录。

三个端对应三条开发线，但它们的核心都挂在后端服务上。换句话说，后端接口设计的是否合理，直接决定前后端联调是否顺利。

2.2 后端技术栈怎么选

技术选型没有标准答案，要看你自己的熟悉程度和导师的偏好。但如果你让我给一个最通用的方案，我会推荐Spring Boot。

为什么是Spring Boot？因为它在国内高校里的普及率太高了，毕业论文写起来资料多，遇到问题随便一搜就有答案，而且Spring Boot自带Tomcat，打成jar包扔到服务器上就能跑，部署成本很低。如果你用的是Java方向，这基本是唯一不太会出错的选项。

当然，如果你对Node.js更熟，用Express或Egg.js写后端也完全没问题。Python方向的话FastAPI或Flask也很轻量。选型的核心逻辑不是哪个语言更牛，而是你能否独立完成所有代码的编写和调试。毕设答辩时老师会问细节，你选一个自己不熟悉的技术栈，最后是给自己挖坑。

后端要提供哪些接口？这里列一下核心模块的接口清单，方便后续设计数据库：

• 用户模块：微信登录（code换openid）、注册、获取用户信息、管理员登录
• 音乐模块：歌曲列表（分页）、歌曲详情、按分类/关键字搜索、热门榜单
• 歌手模块：歌手列表、歌手详情、歌手入驻申请
• 收藏/评论：添加收藏、取消收藏、我的收藏列表、发表评论、评论列表
• 管理端：歌曲添加/修改/删除/审核、歌手管理、用户管理、统计报表

2.3 数据库核心表设计

数据库设计是最能体现一个开发者基本功的地方。音乐管理系统的核心表大致有这几张：

用户表（user）：存储用户的openid、昵称、头像、角色（普通用户/歌手/管理员）、状态。openid是微信用户的唯一标识，必须建唯一索引。

歌手表（singer）：存储歌手姓名、艺名、头像、简介、入驻用户ID、审核状态。用户申请入驻成为歌手后，管理员审核通过才会出现在前端。

歌曲表（song）：这是最核心的表，字段包括歌名、歌手ID、专辑名、封面图URL、音频文件URL、歌词、分类、播放量、下载量、上传者ID、审核状态、创建时间。

分类表（category）：流行、民谣、摇滚、电子等音乐分类，歌曲表通过分类ID关联。

收藏表（favorite）：用户ID + 歌曲ID的组合表，唯一约束（user_id, song_id），避免重复收藏。

评论表（comment）：用户ID、歌曲ID、评论内容、父评论ID（支持楼中楼）、创建时间。

订单表（order）：如果做会员付费或单曲购买，需要这张表，存用户ID、金额、订单号、支付状态、支付时间。

表与表之间的关系不复杂，核心就是用户-歌曲多对多（通过收藏、播放记录关联），歌手-歌曲一对多，分类-歌曲一对多。设计时注意一点：不要在业务表里存太多冗余字段，比如在song表里不要直接存歌手姓名，应该存singer_id，需要名字时联表查，这样以后改歌手昵称不用连带更新歌曲表。

2.4 小程序端：原生还是uniapp

小程序端的开发方式分两条路：原生微信小程序，或者uniapp跨端框架。

原生小程序的好处是轻量、没有框架层转换损耗，wxml/wxss写起来就是HTML/CSS的变体，API调用最直接，调试也方便。坏处是不能一套代码跑多端，以后想上支付宝小程序或者抖音小程序，得重新写。

uniapp的好处就是一套代码多端编译，对于将来想扩展的开发者来说更省事，而且它用Vue语法写，如果你熟Vue，上手比原生还要快。坏处是遇到一些比较偏门的小程序API时，uniapp的封装不一定跟得上，最后还是得写条件编译。

我的建议是：如果你只做微信端，时间还紧，直接原生开发。如果论文里想写“跨平台”“多端适配”这种研究点，就上uniapp。两者都不算难，关键是别中途切换。

3. 核心功能模块与关键技术实现

3.1 用户端：从登录到听歌的完整链路

微信小程序的登录和普通Web登录不一样，它走的是微信授权体系。标准流程是：前端调用wx.login()拿到一个临时code，把code发给后端；后端拿着code去微信接口服务换openid和session_key；拿到openid后查数据库，如果用户不存在就自动注册，存在就更新登录态；最后后端生成一个自定义的token返回给小程序端，后续所有需要鉴权的请求都带上这个token。

这个流程里有两个坑需要提醒一下。第一，wx.login()拿到的code只能用一次，而且有效期只有5分钟，别在中间环节缓存它。第二，现在小程序获取用户头像昵称不能用wx.getUserProfile()这种老接口了，新规是用户点击头像组件时主动授权，你需要在页面上放一个button组件，open-type设为chooseAvatar，昵称则用input的type="nickname"。这个改动让很多旧教程直接失效，你照着新式子写就行。

用户登录以后，主流程就是浏览首页、搜索音乐、进入播放页、收藏评论。首页一般展示推荐歌单、热门榜单、分类入口。这个“推荐”逻辑不需要做多智能，按播放量倒序、按最新上传时间倒序、按分类随机取一批，这些都是最简单的SQL排序问题，但视觉呈现上要有一个像样的榜单UI，这就靠设计稿和样式功底了。

播放器是整个小程序端技术含量最高的部分。微信小程序里播放音频用wx.createInnerAudioContext()接口，这个接口的能力比HTML5的audio标签强大很多，支持后台播放、倍速播放、播放进度监听。但要注意，小程序在切后台或者熄屏时，音频播放的行为受用户操作和系统限制，如果你只是简单的音频播放，在App.json里配置requiredBackgroundModes为audio，可以支持后台播放，但要特别注意这会影响审核，如果系统没有真正的后台播放需求，不建议开。

3.2 音乐文件上传与播放的存储方案

音乐文件是特殊的二进制资源，不能像普通字符串字段那样存入MySQL，所以必须做对象存储。常见方案有三种：

第一种，把音频放在服务器的磁盘目录中。后端接口接收上传文件后，保存到配置的上传目录，然后把访问路径存到数据库。这种方案成本最低，但服务器带宽有限，并发高的时候播放会卡。

第二种，使用云存储服务，比如微信云开发的云存储，或者各大云厂商的OSS/S3。上传时小程序端直接直传云存储，拿到文件ID，后端存这个ID。播放时再换取临时链接，或者直接使用云存储提供的CDN加速地址。这种方案播放体验最好，但会产生少量存储和流量费用。

第三种，混合方案。开发阶段用本地服务器存储，上线后用云存储。很多毕设项目实际都是这么干的，因为开发期没有域名备案，微信小程序的后台downloadFile合法域名只能填HTTPS地址，本地环境根本没法真机加载音频，所以干脆先用开发者工具或者局域网环境调试，等部署上线了再切云存储。这里要注意，如果你用的是云开发，小程序端存储是可以直接带CloudID获取的，不需要配置合法域名，这也是云开发在小程序项目中越来越受欢迎的原因。

对于音频文件的校验，后端在接收上传时一定要做两件事：一是限制文件大小，比如单曲不超过20MB，上传接口在Nginx或Spring配置里都要设限制，否则大文件直接打爆内存；二是校验文件格式，只允许mp3、m4a、flac这类常用格式，在后端判断Content-Type或者扩展名都行，别只靠前端校验，攻击者完全可以绕过前端直接调接口。

3.3 管理后台：歌曲审核与数据统计

管理后台的核心功能就一句话：让管理员能看见所有数据，并对关键数据做增删改查。页面不需要花哨，但列表要全，操作要顺手。

歌曲管理是最重要的模块。管理员需要在后台看到所有已上传和待审核的歌曲列表，能试听（内嵌一个audio标签播放），能修改歌曲信息（歌名、分类、歌词），能下架违规歌曲，能删除垃圾数据。

审核功能怎么设计？在song表里加一个status字段：0表示待审核、1表示已上架、2表示已下架、3表示审核驳回。用户在C端上传新歌后，status默认为0，C端查询歌曲列表时只查status为1的数据。管理员的待审核列表展示status为0的数据，点击通过就把status改为1，点击驳回就改成3并填写驳回原因。这个状态机不复杂，但它是审核类系统的基础，理解了它，以后做文章审核、视频审核都是一样的套路。

另外一个实用功能是数据统计看板。音乐平台的统计维度比较多：总用户数、总歌曲数、总播放量、近一周新增用户曲线、歌曲分类占比饼图、歌手排行Top10。这些统计接口在后端写几个SQL聚合查询就行，管理端再接一个图表库，比如ECharts，就能做出像模像样的可视化页面。这部分在毕设答辩时是加分项，因为老师看到图表会以为你的系统用了大数据分析，其实底层就是简单的count和group by，但呈现效果确实好。

3.4 微信支付v3对接：会员与付费场景

标题的热搜词里提到了“小程序微信支付v3对接”，这个必须单独说一下。很多音乐小程序会做会员功能，用户付费成为VIP后才能听VIP歌曲或下载无损音质，这就涉及微信支付。

微信支付现在主推的是APIv3版本，跟老版本最大的区别是：所有请求都用微信支付平台证书加签，使用AES-256-GCM对敏感信息加密，回调通知也需要用APIv3密钥解密。所以对接v3时的核心步骤是：

• 申请商户号，配置商户API密钥，下载商户证书。
• 后端生成签名，使用的是微信支付APIv3要求的SHA256-RSA2048签名。
• 小程序端调用wx.requestPayment()发起支付，需要传给微信的参数是后端下单后返回的5个参数：timeStamp、nonceStr、package、signType、paySign。
• 支付成功后微信服务器会异步回调你的回调地址，回调里需要解密resource字段中的密文，取出订单号、支付金额，然后更新订单状态。

整个流程里最容易出问题的是签名和证书配置。很多同学照着教程写完之后调不通，十有八九是证书路径配错了，或者签名串拼接的字段顺序不对。调支付接口的时候别上来就写业务代码，先用微信支付官方提供的Postman调试工具把例子跑通，确认证书和密钥没问题，再接入自己的业务逻辑。

还有很重要的一点：小程序里要开通微信支付，账号主体必须是企业或个体工商户，个人开发者是无法开通的。另外支付类目需要提交资料审核，如果你用的是未认证的个人小程序，支付功能根本用不了。所以如果毕设项目只是演示，建议做一个模拟支付的功能，在前端做一个假的支付页面，选择“模拟支付成功”后直接回调成功接口，并在论文里说明这是为了演示流程做的替代方案，这样既不影响答辩演示，也避免了资质问题。

3.5 原创版权与歌手入驻流程

“原创音乐”是这个项目的定位，那原创身份认证就得做进去。合理的业务设计是：用户可以在小程序端提交“歌手入驻申请”，填写艺名、个人简介、上传头像，后端把申请数据写入singer表，status设为待审核。管理员在后台审核通过后，这个用户的角色就从普通用户变成了singer角色。

成为歌手之后，用户就可以在作品管理页面里上传自己的原创歌曲。上传时要填写歌名、选择分类、上传封面和音频文件。这些歌曲默认是待审核状态，不能立刻被其他用户看到，等管理员审核通过后才会出现在公共曲库中。

从这种设计里能看出一个隐含逻辑：系统把“用户产生内容”的流程完整闭环了。这也是为什么这个项目比普通的图书管理系统好讲的原因，它的一切业务都是在围绕原创内容的生产与消费做文章，论文的背景和现实意义非常清晰。

4. 从零到完成：实操全流程记录

4.1 环境准备与项目初始化

动手开发之前，先把环境准备好。你需要的东西有：

• 微信开发者工具，去微信官网下载稳定版。
• 一个微信小程序账号，去微信公众平台注册。个人主体能注册小程序，但部分功能受限，前面说过了。注册完成后拿到AppID，这在开发者工具里创建项目时要用。
• 如果做原生开发，不需要额外安装脚手架，微信开发者工具自带模板。如果是uniapp，需要先安装HBuilderX或者用Vue CLI创建uniapp项目。
• 后端开发环境，以Spring Boot为例：JDK 8+、Maven、IDE。
• 数据库：MySQL 5.7或8.0，Navicat或命令行工具。

初始化项目时，先不要急着写页面。建议先把项目目录结构规划好，小程序端分为pages、components、utils、api这几个目录。pages存放页面文件；components存放自定义组件，比如播放控制条、歌曲卡片；utils存放公共工具函数，比如格式化播放时长；api目录统一封装所有后端接口请求。后端按照controller、service、mapper、entity、config分层。这套目录规范尽早建立，后期加代码时不用东一个西一个地找。

4.2 开发阶段的关键细节：顶部导航栏与页面适配

小程序开发里有一个很让新手头疼的问题，就是顶部导航栏高度在不同机型上不一致。热搜词里也出现了“微信小程序顶部导航栏高度”和“微信小程序内嵌H5工具栏左侧返回箭头没有了”，说明这是高频坑。

先说顶部导航栏。默认情况，微信小程序的导航栏高度在iPhone上是44px，在Android上是48px，再加上状态栏（就是显示电量、时间的那条黑条）高度，在不同手机上有差异。如果你要做自定义导航栏，比如想让标题栏跟页面背景融为一体，就必须动态计算导航栏高度，公式是：导航栏总高度 = 状态栏高度（wx.getSystemInfoSync().statusBarHeight）+ 导航栏自身高度（通常是44px）。

至于内嵌H5后返回箭头消失的问题，原因一般是Web-view页面的导航栏和宿主小程序的导航栏做了叠加或覆盖。最简单的解法是：内嵌H5页面时关闭小程序的导航栏，让H5自己管理返回逻辑，或者在小程序导航栏的左上角手动放一个返回图标，调用wx.navigateBack()。

这些看起来都是小细节，但恰恰是这些细节决定了你做出来的小程序像不像一个“能上线的产品”，而不是一个翻页Demo。

4.3 后端接口开发与小程序联调的节奏

联调是项目开发中最容易拖时间的环节，规划好节奏能省很多事。我推荐按模块逐个联调，而不是等后端全写完再统一调。

大致节奏是这样的：

• 第一步：先做用户登录模块，把小程序端登录、后端换openid、token下发的链路跑通。这个模块通了，后面所有带token的请求就都有基础了。
• 第二步：做歌曲列表和详情页，先把后端的list接口和详情接口调通，小程序端能看到列表数据，播放器能播放音频。
• 第三步：做收藏和评论，这两个模块依赖用户token，需要先确认登录态。
• 第四步：做管理后台。后台的核心模块是歌单管理和用户管理，可以先通过Postman调通接口，再去做前端页面。
• 第五步：做统计看板和数据审核流程。

每一个模块联调通过，就相当于完成了一个里程碑，即使中途卡住也不至于影响全局。

联调时有一个工具要熟练使用：微信开发者工具自带的Network面板。请求是否发出、返回什么状态码、响应数据长什么样，一目了然。遇到接口报错，先在Network里看是不是跨域或者域名配置问题，再看后端的控制台日志，不要瞎猜。

4.4 部署上线：域名、HTTPS与配置

小程序上线和Web上线的差异很大。Web部署到服务器后配个域名就能访问，小程序不行，它有一套严格的审核机制。

首先，所有小程序发起的网络请求域名必须是HTTPS的，而且必须在微信公众平台的后台里配置到“服务器域名”中。你本地开发时可以在开发者工具里勾选“不校验合法域名”，但真机预览和上线审核时这个选项不存在，全部域名都会按合法域名来校验。

所以部署流程应该是：

• 买一台云服务器，装好JDK、MySQL、Nginx。
• 给域名申请SSL证书，配置HTTPS。
• 把后端服务打包并启动，Nginx做反向代理，把API请求转发到后端的端口。
• 在微信公众平台配置request合法域名和downloadFile合法域名。
• 小程序端把API的baseUrl从http://localhost改成你的HTTPS域名。
• 提交审核前，先用开发者工具的“预览”功能在真机上完整跑一遍流程。

另外，如果你的后台管理端也用同一个域名的不同路径部署，注意跨域问题。Nginx可以统一处理跨域头，小程序端没有跨域问题但浏览器端有，管理后台的接口请求需要后端配置CORS，这个很关键。

5. 高频问题与排错经验速查

项目开发过程中遇到的问题，我按经验把它们分成了几类，整理成表格供参考。

再补充几个运营层面的细节：

第一，数据安全要注意。不要把数据库密码、微信小程序的AppSecret写在前端代码里，这些机密信息一旦泄露，别人可以冒用你的小程序身份调用接口。AppSecret只能放在后端。上传歌曲的接口一定要做登录校验，防止任何人未经登录直接灌数据。

第二，小程序审核被拒是家常便饭。常见被拒原因包括：类目选择不对、涉及音乐播放但没有版权资质、界面有测试字样、隐私政策缺失。你做毕设演示的话，可以在小程序名称后缀加“演示版”，并在提交审核时声明仅用于学习交流。如果是个人开发且无法提供音乐版权证明，审核可能比较难通过，这时候就要在论文里明确说明系统的定位是技术演示，实际运营需要额外申请资质。

第三，排查问题时别乱改代码。先复现现场，再看日志，最后定位改代码。很多同学遇到bug第一反应是来回改前端代码，结果发现是后端接口没通，白白浪费时间。我分享一个习惯：联调阶段，先用Postman把后端接口全部测一遍，确认后端稳定了再动小程序端。这样出现问题就能快速把责任范围锁定在前端还是后端。

6. 论文说明：怎么写才不容易被老师挑毛病

标题里带了“论文说明”，说明你不仅要做出系统，还要写出一篇像样的论文。很多同学代码写得还行，一到写论文就痛苦不堪，这里分享一个论文写作框架，照着填充内容就行。

第一章绪论：重点写研究背景和意义。不要写空话，要结合现在独立音乐人越来越多、线上音乐平台版权费用高、小众音乐人缺少展示渠道这些现实情况，把系统定位在“为原创音乐人提供一个作品管理和展示平台”。研究现状部分，整理两三个现有的音乐平台比如主流音乐App的优点和不足，对比后引出你的系统。

第二章相关技术介绍：把论文里用到的核心技术逐一介绍。微信小程序开发框架、Spring Boot、MySQL、Nginx、对象存储。每一部分简单说原理和为什么选它，不要大段抄书，老师都知道你是百度来的。

第三章系统分析：写可行性分析（技术、经济、操作三个维度）和需求分析（功能需求、非功能需求）。画用例图，列出用例说明。这一章是凑字数的好地方，但要确保每个用例都对应到真实的系统功能。

第四章系统设计：总体架构设计、功能模块设计、数据库设计（ER图 + 每张表的字段说明）。数据库设计部分要写清楚每个字段的含义和约束，这是老师爱细看的地方。

第五章系统实现：按功能模块分节写实现过程。每节先写流程，再贴关键代码片段，然后放运行截图。记得不要贴大段源码，老师没时间逐行看，挑核心逻辑代码展示就行。比如播放器初始化、登录鉴权、上传接口、管理端审核流程，这四个点足够撑起整章。

第六章系统测试：写测试环境、测试用例、测试结果。功能测试用表格列用例：用例编号、测试步骤、预期结果、实际结果、是否通过。性能测试简单用Postman或者JMeter跑一下接口响应时间，截图贴上去。兼容性测试列几个常见机型。

第七章总结与展望：总结做了什么，有哪些不足，未来怎么改进。这里最忌讳写得太虚，比如“系统还有不足，未来将进一步完善”，这种话谁都会写。要写具体，比如“目前播放量统计仅记录了总次数，后续可以增加按时间段维度的统计图表；评论功能尚未支持@提醒和消息通知；推荐算法是简单的播放量排序，未来可以引入协同过滤算法”。

论文里图表的数量和质量直接影响印象分。除了架构图、ER图、用例图、流程图，还可以画时序图，写登录流程和支付流程时画一张，老师会觉得你的设计很完整。画图工具用Visio、draw.io或者ProcessOn都可以，关键是线条规范、文字统一。

答辩时老师常问的问题，提前准备一下：

• 为什么选择这个课题？回答要体现你对原创音乐和内容平台的理解，说明你发现了什么痛点。
• 系统中最难实现的功能是什么？很多同学会想到播放器、登录或支付。其实你可以回答上传审核流程，因为涉及文件存储、状态流转、权限控制，能展开讲很多细节。
• 数据库中表之间有什么关系？这个必须清晰介绍user、singer、song、favorite之间的关联。
• 系统有什么不足，如何改进？不要说自己没有不足，显得不真实。提两三个具体的小问题，再给出你的解决思路，这反而加分。
• 项目是否真实上线运行？如果只在本机跑过，就如实说本地开发已验证，并补充说明要上线还需要域名备案、HTTPS配置、内容合规审核等流程。

7. 我的实操体会与最后的小建议

这类项目我前后带过好几个学生完整走下来，整体感受是：难度不在于某个技术点有多深，而在于项目链路太长，任何一个环节断了，整个系统就卡在那里。所以我的建议是按端分阶段推进，先把用户端的主流程打通，再做管理端功能，最后补统计和边缘细节。主流程跑通了，你的心态会完全不同，后面填功能都是水到渠成的事。

另外，代码之外的东西千万别忽略。数据库设计文档、接口文档、测试用例、部署文档这些看似不起眼的材料，恰恰是论文最重要的素材。项目开发的过程中随手记录自己做过的关键决策和踩过的坑，等你开始写论文时，这些记录就是最真实的素材，比临时回忆高效得多。

最后分享一个我被问过很多次的小细节：如果你在演示时发现小程序播放器声音特别小，别急着改代码，先检查手机侧面静音键是不是打开了。Android和iOS的静音策略不一样，iPhone在静音模式下InnerAudioContext的播放音量会受影响。这种看起来像bug的“bug”，检查一下硬件开关往往比调试半天代码更有效。

做这类全栈项目，本质上就是逼自己把整个技术栈穿一遍。做完以后你对前端交互、后端接口、数据库设计、服务器部署的认知，会远远超过只看教程的阶段。项目本身能不能成为产品不重要，这个从零到一的过程，才是最有价值的东西。