最近不少朋友在准备毕业设计或项目实战时都盯上了“校园短视频”这个方向。说实话用Python做后端、微信小程序做前端来搭一套大学校园里的短视频社交系统这个组合确实很典型也很有代表性。它既有短视频产品的核心链路又有社交互动的复杂业务还能把Python后端、小程序前端、对象存储、推荐排序这些技术点全部串起来作为简历项目和毕设都属于性价比很高的选题。我前阵子刚好完整地做过一个类似的系统从需求拆解、后端API设计到小程序端视频流播放、发布流程再到上线前遇到的各种坑前前后后踩了不少雷。这篇文章就把我当时的设计思路和实操过程梳理一遍重点讲清楚每个模块是怎么实现的、为什么要这么设计以及那些文档里查不到的血泪经验。不管你是准备做毕设还是想做一个能 demo 的项目这份内容都能让你少走很多弯路。1. 项目拆解大学校园短视频不是“小抖音”1.1 需求边界先搞清楚要解决什么问题很多同学一拿到“校园短视频社交系统”这个题目第一反应就是照着抖音抄一个。但校园场景和公网场景有本质区别需求边界完全不同。校园产品的核心场景是用户群体集中在某个校园区域内容高度围绕校园生活食堂、宿舍、社团、自习室、运动会社交关系基于现实中的同学、学长学弟。这意味着系统不需要复杂的个性化推荐算法而是更需要“校园话题聚合”“附近的人”“同院系内容流”这种强校园属性的功能。我当时把需求拆成了四个核心模块。用户模块微信登录绑定学生身份支持学院、年级、专业等资料完善。短视频模块视频发布、播放、删除封面选择视频信息维护。社交模块点赞、评论、关注、收藏个人主页展示作品、点赞、收藏列表。内容传播模块基于校园话题的聚合流、基于关注关系的关注流、基于时间或热度的推荐流。对比一下商业短视频产品校园系统砍掉了直播、私信、商品橱窗、复杂的推荐策略但增加了校园认证、话题聚合、同校内容流这些差异化能力。这个取舍不是随意做的而是基于一个原则让开发闭环在可控范围内同时把短视频和社交的核心链路都覆盖到。1.2 技术选型为什么是Python后端加微信小程序后端选Python核心原因是开发效率和生态。Python在Web开发这块有非常成熟的框架比如FastAPI和Django REST Framework这些框架自带ORM、数据库迁移、接口文档、参数校验能让开发者在短时间内把完整业务跑通。具体到短视频系统我最终选了FastAPI。原因很直接。异步支持好视频上传和Feed流这类IO密集型操作能扛住并发。自动生成OpenAPI文档小程序端联调的时候可以直接对着文档调试接口。自带Pydantic参数校验避免小程序端传参不规范导致后端疯狂报错。代码量比Django更精简适合单人项目快速迭代。前端选微信小程序也有非常现实的理由。微信小程序免安装、打开即用在大学校园这种场景里传播立刻不需要用户额外下载App。同时微信生态里自带登录、分享能力开发成本比单独做App低一个数量级。尤其是对于毕设场景小程序端的实现工作量可控又能体面地展示移动端交互能力。需要注意的是如果你的目标是搞一套多端复用的系统可以考虑uniapp。但如果就做微信小程序本身原生小程序的性能和调试体验反而更好尤其视频类页面原生video组件的表现比多端框架的封装更可控。1.3 整体架构一条完整的数据链路系统整体架构可以分为四个部分小程序客户端、后端服务、数据存储、对象存储。前端小程序负责视频流展示、拍摄上传、用户交互。后端服务基于FastAPI提供账号认证、视频管理、Feed流、社交互动这些API。数据存储用MySQL存结构化数据用户、视频信息、点赞关系、评论等Redis做缓存和热门数据加速。对象存储用于存放视频文件和封面图片配合CDN加速播放。整个数据链路是这样的用户在小程序端选择视频文件通过后端获取上传凭证直传对象存储完成后回调后端更新视频信息。内容流接口从MySQL读取视频元数据并通过Redis对热点数据进行加速。点赞评论等互动操作先更新Redis计数再异步落库。这个架构最大的好处是分层清晰。每个部分都可以独立测试且后端不直接维护视频文件避免了Web服务压力过大的问题。2. 后端核心设计与API实现2.1 项目初始化目录结构和环境准备后端项目结构我按业务模块做了拆分而不是按技术类型拆分这样后续加功能时能快速定位。一个可参考的目录结构大概是这样的。app/ ├── main.py # FastAPI入口 ├── config.py # 配置信息 ├── database.py # 数据库连接 ├── models/ # SQLAlchemy模型 │ ├── user.py │ ├── video.py │ ├── comment.py │ └── interaction.py ├── schemas/ # Pydantic模型 ├── api/ # 路由层 │ ├── auth.py │ ├── video.py │ ├── feed.py │ └── social.py ├── services/ # 业务逻辑层 │ ├── video_service.py │ ├── feed_service.py │ └── user_service.py └── utils/ # 公共工具依赖管理用requirements.txt就够了没必要上Poetry。核心依赖是fastapi、uvicorn、sqlalchemy、pymysql、redis、python-jose、passlib。启动方式就是uvicorn app.main:app --host 0.0.0.0 --port 8000。配置这块有一个很实用的建议不要把所有配置硬编码在代码里建议放在.env文件或config.py中集中管理。对象存储密钥、数据库地址、微信小程序AppSecret这些敏感信息千万别直接写死在代码里无论是毕设答辩还是上线部署都是减分项。2.2 用户认证与校园身份绑定微信小程序的登录流程是基于wx.login获取临时code后端用code换openid和session_key。整体闭环是这样运作的。小程序端调用uni.login或wx.login获取code把code发送到后端/auth/login接口。后端拿着code去调微信接口换取openid和session_key然后查询用户是否已存在。如果用户不存在就创建新账号最后签发一个自定的token我用的是JWT返回给小程序端。这里有个关键点不要直接存openid之外还暴露openid给前端更不要把session_key返回给前端。session_key是微信会话密钥前端不需要也不应该拿到。还有用户的登录态不要用微信返回的code做tokencode是一次性的必须由后端换取真实身份信息后再自定义token。校园身份绑定我放在登录之后通过/auth/bind-campus接口完成。用户提交学校、学院、学号、姓名后端校验学号格式不同学校的学号规则不同可以用正则做基本校验绑定后用户主页展示校园信息。这块的核心价值是内容流的同校属性所以我给User模型加了campus_id字段后续Feed流可以按这个字段做内容过滤。2.3 视频上传链路从直传到转码视频上传是整个系统里最容易出问题的环节没有之一。我最终采用的是“小程序端直传对象存储”的方案而不是“小程序先传后端再转存对象存储”的方案。两种方案的区别在于直传方案是后端先生成上传凭证比如对象存储的临时密钥或签名URL小程序拿到凭证后直接把视频上传对象存储上传完成后再通知后端“我传完了这是我的视频信息”。中转方案则是小程序把视频先传到后端服务器后端再转存对象存储等于视频流经了你的Web服务。中转方案的优点是代码简单小程序端只调后端一个接口就行但代价非常大。你的后端带宽会成为瓶颈视频上传耗时成倍增加而且后端服务器存储压力、流量费用都会暴涨。如果多个用户同时上传视频后端服务直接可能卡死。所以只要对象存储支持直传一定要用直传方案。我当时的完整上传流程是小程序端请求POST /video/upload-token传入视频大小和类型。后端校验用户登录态生成并返回上传凭证有效期设置短一点比如10分钟。小程序拿到凭证后直接把视频文件传到对象存储同时手动指定一个object名称一般是userId_timestamp.mp4这种格式。上传成功后小程序调POST /video/create接口传视频标题、描述、封面地址、视频地址、校园话题ID等元数据。后端在video表中创建记录并把这个视频的id返回给前端。这个流程看似简单但有三个细节容易被忽略。第一封面的问题。短视频在小程序端展示需要封面图不能直接让video组件加载视频首帧体验很差。更靠谱的做法是在发布页让用户选择封面如果不想增加用户操作也可以在后端使用ffmpeg对视频抽帧生成封面。我当时是后端用ffmpeg截取视频第1秒的某一帧作为自动封面用户也可以后续修改封面。第二视频格式和尺寸校验。小程序端虽然能识别视频文件但后端在create接口必须校验视频地址的后缀、文件大小、视频时长。我用的是一个简单的规则时长在3到60秒之间大小不超过50MB格式是mp4或mov。超出范围的直接拒绝避免对象存储里混入异常文件。第三视频转码和清晰度。如果是毕设demo这一步可以不做直接用原视频播放。但如果想做得更完整可以在后端接一个异步任务队列Celery或者简单的消息队列对上传后的视频做转码生成720p或1080p的播放版本。考虑到部署成本我当时直接用ffmpeg做了一次轻量转码把超过1080p的视频压到1080p同时抽帧生成封面。这一步在后端用subprocess调用ffmpeg命令行完成代码不复杂但收益很明显。2.4 Feed流设计时间流、关注流、热度流Feed流是短视频系统最核心的接口没有之一。我在系统里实现了三种Feed流分别对应不同的用户需求。时间流是默认的推荐流按发布时间倒序返回最新视频。这个流的实现最简单SQL就是按created_at倒序分页查询。但有个细节要考虑热门视频可能持续霸占信息流前排导致新视频曝光不足。我在时间流里加了加权策略让发布时间在最近24小时内且互动率较高的视频适当靠前同时保留时间倒序的整体调性。关注流只返回当前用户关注的人发布的视频。实现上依赖关注关系表查询时先拿当前用户的关注列表再按这些作者的视频发布时间倒序返回。这是典型的“先查关系再查内容”模式如果关注的人很多可以缓存关注列表到Redis避免每次请求都全表扫描。热度流基于一个简单的热度分热度分 播放量 * 0.3 点赞数 * 0.5 评论数 * 0.2 分享数 * 0.4再配合时间衰减因子。这个公式不复杂但比纯时间流更接近真实的短视频推荐逻辑。实际项目中可以把热度分定期计算后存到Redis的有序集合里Feed流接口直接读Redis性能非常好。考虑到校园场景的用户量级几千到几万人我不建议在毕设阶段引入复杂的推荐算法。基于时间、关注、热度三种策略已经能完整展示设计能力答辩时讲清楚每种流的适用场景远比甩一个不成熟的协同过滤模型更有说服力。数据库层面的分页也有很多讲究。不要用OFFSET做深分页因为数据量大后OFFSET性能断崖式下降。更可靠的方式是基于游标分页也就是记录last_id或created_at下一页查询时带上这个值。我当时在视频表的id和created_at上建了复合索引Feed流查询效率非常稳定。2.5 社交模块点赞、评论、关注的数据模型社交模块的数据模型设计直接决定后续开发和查询的复杂度。我的核心建议是关系数据单独建表不要用JSON字段。点赞表的核心字段是id、user_id、video_id、created_at唯一索引建在user_id和video_id上保证同一用户对同一视频只能点赞一次。取消点赞就是删除这条记录不是更新状态字段。这样设计的好处是数据干净统计“是否已点赞”只需要一条索引查询。评论表核心字段是id、video_id、user_id、content、parent_id、created_at。parent_id用于回复评论的场景为空表示这是一级评论。这个表是高频访问表video_id和created_at的复合索引必须建好否则评论列表在数据量大后会非常卡。关注表核心字段是id、follower_id、followee_id、created_at唯一索引建在follower_id和followee_id上。关注关系的判断也是高频操作可以在Redis里存一个用户关注集合的缓存比如key为follow:set:{userId}value是关注的所有人id。互动计数的问题值得单独说。如果每次点赞都直接UPDATE视频表的like_count字段在高并发下会有锁竞争而且点一次赞更新两次加点赞数、减点赞数会产生大量无效写操作。我的做法是互动操作先更新Redis计数比如INCR video:like_count:{videoId}然后异步批量把计数同步到MySQL。如果项目周期短不做异步也行直接同步更新也能跑但Redis缓存方案在答辩里绝对是个加分项。评论列表返回时还需要返回评论者的头像、昵称信息。这里要避免N1查询问题也就是循环查每个评论的作者信息。正确做法是先用评论文本关联出所有user_id一次性IN查询所有用户信息然后内存里做关联拼接。N1问题在短视频系统里特别容易暴露因为首页Feed流一次返回十几条视频每条视频又要拼作者信息如果不做批量查询一条接口请求会变成几十条SQL。3. 小程序端页面结构、视频流与发布实现3.1 项目结构与基础配置小程序端的开发我建议直接用原生因为视频相关组件和性能调优在原生环境更好控制。项目的基础结构大概是miniprogram/ ├── app.js ├── app.json ├── app.wxss ├── pages/ │ ├── feed/ # 首页视频流 │ ├── publish/ # 发布视频 │ ├── profile/ # 个人主页 │ ├── login/ # 登录/校园认证 │ ├── video-detail/ # 视频详情与评论 │ ├── message/ # 通知或消息 │ └── search/ # 校园话题搜索 ├── components/ │ ├── video-card/ │ └── comment-item/ ├── utils/ │ ├── request.js # 封装请求 │ └── auth.js # 登录态管理 └── static/app.json里的关键配置是tabBar我设置的底部导航是首页、发布、我的三个入口。发布页放中间位置符合主流短视频产品的交互习惯。为了引导用户发视频发布页也可以做成一个只有按钮的中间页点击后跳转到真正的发布操作页。全局请求封装是必须做的。小程序原生request不处理业务状态码也不自动带token所以一定要在utils/request.js里统一封装。我封装的逻辑是每个请求自动带上token后端返回401时自动清理本地登录态并跳转登录页后端返回业务错误码时统一提示错误信息。这个封装能避免在十几个页面里重复处理登录过期的问题。3.2 首页Feed流视频列表的滑动手感首页Feed流是整个项目体验的重中之重。这里有两个常用方案一种是上下滑动的全屏卡片流类似抖音另一种是列表嵌套视频组件类似微博。全屏卡片流更贴近短视频产品形态交互上用swiper组件纵向滑动实现一屏一视频。这种方案的问题是每个播放页的video组件如果都自动播放会同时加载多个视频资源流量消耗和性能压力都很大。我的处理方式是只播放当前可见的视频卡片其他卡片暂停或者不加载数据源。具体实现时我监听swiper的bindchange事件拿到当前activeIndex后动态设置当前视频的src其余视频组件的src置空。这样每次只真正加载一个视频流滑动时自动暂停上一个。配合video组件的autoplay属性播放体验接近抖音的原生手感。另外一个关键细节是小程序iOS端视频组件层级问题比较明显尽量避免在video上方悬浮复杂组件否则可能出现渲染层级错乱。封面图放在video组件内部作为poster值而不是覆盖一个image在video上面这个习惯能规避很多层级问题。列表嵌套方案简单一些但性能会随着页面滚动下降。如果视频数量较多列表页面最终会卡顿因为它一次性渲染了太多video组件。如果是做毕设demo列表方案可以接受但如果你想展示更佳的工程能力全屏滑动方案一定是更亮眼的选择。3.3 发布流程从选片到上传成功的完整闭环发布页是整个小程序端逻辑最复杂的一页。整个流程是用户选择视频文件确认封面填写标题和话题触发上传展示进度条上传完成后提交信息跳转回首页。选择视频可以使用微信提供的wx.chooseVideo或wx.chooseMedia可以设置maxDuration限制时长。拿到临时文件路径后用户可以在发布页预览同时通过后端的上传凭证接口获取上传凭证。上传动作使用wx.uploadFile但要注意直传对象存储和传统表单上传有一个地方不同。如果你直传时使用的是腾讯云COS的临时密钥方式签名算法需要小程序端自行计算这对毕设不友好。更省事的方式是用后端的预签名URLPUT方式直传小程序端通过wx.request发起PUT请求把文件内容写入预签名URL。或者也可以用对象存储提供的客户端SDK云开发环境甚至可以直接用uniCloud或微信云开发的存储能力省去签名流程。发布信息提交时注意把视频时长、文件大小、宽高这些元数据一并提交给后端。我在前端通过wx.getVideoInfo获取视频的时长和尺寸上传时把这些参数放在create接口里。后端接收到这些元数据可以做时长校验也可以为后续转码或抽帧提供输入。发布进度条是体验的重要细节。虽然原生wx.uploadFile不支持分片上传进度回调但对象存储的客户端SDK一般都能拿到上传进度可以用来驱动进度条展示。3.4 视频详情页评论与互动的实现视频详情页承载的是社交互动点赞、评论、收藏、分享。这一页的用户路径是从Feed流点击视频卡片进入详情查看完整视频信息和评论点赞评论或收藏也可以关注视频作者。详情页的数据加载分为两部分视频详情、评论列表。视频详情的接口返回视频元数据、作者信息、当前用户是否点赞、是否收藏以及播放量、点赞数、评论数这些计数。评论列表我采用了分页加载每次加载10条滑动到底部自动加载下一页。点赞功能的交互细节推荐做成乐观更新。也就是用户点击点赞图标时前端立即更新UI图标变红、数字加一同时异步请求后端接口。后端接口返回失败时再回滚UI状态。如果没有乐观更新每次点击都要等网络往返很容易造成“点了没反应”的错觉。评论功能则简单很多输入框提交评论成功后刷新评论列表同时评论数加一。关注按钮在详情页和作者主页都会出现。关注操作也建议乐观更新点击后按钮状态从“ 关注”变为“已关注”同时后端建立关注关系。个人主页中我的页面和他人页面应该复用同一个页面组件通过路由参数区分userId。自己看自己时展示“作品/点赞/收藏”三个tab看别人时展示“作品/点赞”两个tab这样交互更清晰。4. 关键难点与性能优化流量、缓存与稳定性4.1 视频播放体验预加载与封面策略校园场景里Wi-Fi覆盖率不算差但5G流量也不是人人都有。视频播放体验优化核心是减少不必要的流量开销同时提升播放顺畅度。我做了三件事。第一封面图统一走对象存储的压缩处理让封面图尺寸控制在合理范围一般设置为宽度750px左右即可。第二全屏卡片流中当前视频的poster直接展示封面滑动到下一个时再开始加载视频资源。第三Feed流接口返回的视频列表带上视频时长和清晰度标记小程序端在非Wi-Fi环境下可以提示用户或自动选择流畅清晰度。比较反直觉的一点是不要对所有视频都做预加载。预加载等于提前消耗流量在校园网环境下可能拖垮体验。控制好加载时机只在Wi-Fi环境下且用户滑动停顿超过一定时间时才预加载下一个视频这是更平衡的方案。4.2 缓存设计Redis的热点key策略短视频系统的热点数据集中在两块Feed流列表和互动计数。Feed流列表是我Cache Aside模式的重点。以时间流为例第一页的Feed流接口结果在Redis里缓存60秒缓存key可以是feed:timeline:page:1。用户刷新或滑到底部加载第二页时重新请求后端拿最新数据。热度流和关注流可以设不同的缓存时间热度流缓存90秒关注流缓存30秒。这些缓存让压测时接口响应从几十毫秒变成个位数毫秒提升明显。互动计数使用Redis的整型自增操作。每个视频的点赞数、播放数、评论数都存在单独key里比如video:like_count:1001。点赞操作是INCR取消点赞是DECR播放量是每次进入详情页时INCR。这里要注意数据一致性问题Redis和MySQL的计数最终要同步。我实现的方式是启动一个定时任务每隔几分钟把Redis中的计数批量同步回MySQL同时清理过期key。缓存穿透是我重点防御的问题。如果用户频繁请求一个不存在的视频ID每次都打到数据库Redis完全没缓存MySQL压力会很大。我的做法是在查询数据库后如果数据不存在也在Redis里缓存一个空值缓存时间设短一点比如30秒这样就能有效挡住恶意请求或异常请求。4.3 热点视频本地缓存加Redis的二级保护在答辩或演示时评委可能会问到“如果系统突然火了一个视频会怎样”。这个问题考察的就是热点应对。处理热点视频的经典手段是本地缓存加Redis的二级保护。具体来说热点视频的详情数据不仅缓存在Redis还可以在服务端进程内维护一个热点视频名单出现超高播放量的视频时直接走本地内存缓存不经过网络IO。本地缓存我用的是简单的字典加过期时间没有引入额外的缓存库。热点视频名单怎么确定依靠播放量阈值比如一个视频的播放量在某个时间窗口内超过了设定的阈值就把它放入热点名单。这个机制能有效避免单点缓存失效导致的数据库压力骤增。虽然在毕设里热点流量不会真实发生但在答辩时能讲清楚这个设计证明你考虑到高并发场景是很大的加分项。4.4 安全与合规内容安全是底线短视频系统的内容安全比普通应用要求更严格。我先放下了复杂的AI审核方案而是从平台机制和技术两层做了处理。平台机制层用户发布视频时强制勾选“原创声明”和“遵守校园公约”后端记录实名信息违规内容可以追溯到账号。技术层简单敏感词过滤是一个低成本起步方案。我维护了一个敏感词列表发布时对标题和描述做过滤命中敏感词的直接拦截。视频画面内容的安全审核如果需要完整方案可以接入云服务的内容安全API但毕设阶段用文档说明设计思路即可。另外视频的投诉举报功能必须做。用户在视频详情页可以通过“举报”入口提交举报类型和说明后台有审核页面处理举报记录。这个功能不需要很复杂但它的存在证明你考虑到产品合规性这在答辩中经常被提问。5. 常见问题与排查技巧实录5.1 高频问题速查表我在开发调试的过程中把遇到的高频问题整理成了一张速查表每一条都是实操后的结论。问题现象可能原因排查方向与解法真机预览视频黑屏video组件src在滑动后才赋值但又设置了autoplay把autoplay设为动态绑定src为空时暂停播放检查封面poster是否设置上传视频一直转圈后端返回的上传凭证过期或签名错误检查凭证有效期是否需要重新获取确认对象存储的Bucket区域是否匹配小程序端请求接口404后端路由前缀或端口不一致或请求域名未配置合法域名开发阶段在小程序后台勾选“不校验合法域名”上线前务必配置request合法域名微信登录提示code无效code被重复使用或后端换了AppSecret确认code只能消费一次检查AppSecret是否与小程序后台一致视频列表上下滑动卡顿swiper中同时渲染多个video组件调整加载策略未播放的视频不渲染video使用封面占位评论列表重复出现分页参数传错或第一页请求未结束就发第二页请求加锁或防抖避免重复请求统一游标分页逻辑Redis缓存数据与MySQL不一致定时同步任务时间间隔过长或同步异常被忽略同步任务增加日志和失败重试机制互动计数容忍短期不一致小程序码或分享图片不显示调用了未开通的接口能力或域名未配置确认接口调用权限检查downloadFile合法域名5.2 实战避坑笔记除了表格里那些技术问题还有几个开发过程中的经验想分享一下。第一个是环境问题。开发阶段一定要把小程序后台的“不校验合法域名”打开否则本地联调时所有请求都会被拦截很容易误判成后端写错。但上线前务必关闭这个选项并且把后端域名、对象存储域名全部配置到合法域名列表中。这个流程很多人到了上线环节才发现临时被卡住一两周。第二个是用户身份问题。不要在前端存储openid更不要把openid作为用户标识展示在页面上。openid是微信生态里的敏感身份标识正确做法是后端维护自己的user_id小程序端只操作这个user_id。涉及校园信息的展示也要脱敏学号中间部分打码显示。第三个是关于微信平台的能力限制。小程序发布视频不代表可以无限制使用所有API。像wx.chooseMedia的相机拍摄能力是完整的但如果有涉及直播或特定内容类目平台对类目要求很严格。项目的功能设计和答辩内容要控制在不触碰平台类目限制的范围内。第四个是部署层面的经验。后端不要部署在本地电脑上让人用局域网访问这样演示时一旦断网或电脑休眠整个系统就挂了。更稳妥的方式是部署到一台云服务器上阿里云或腾讯云的学生机即可配置好HTTPS证书小程序端请求走HTTPS这样真机预览也能直接访问演示效果会好很多。最后一个我认为非常重要的经验是备份。数据库和对象存储里的内容要定期备份开发过程中经历过对象存储误删文件、数据库被跑崩的意外。不要觉得毕设项目不需要备份开发到后期如果本地代码或数据库丢了心态真的会崩。写在最后这篇文章里的所有经验都来自我完整开发一个校园短视频系统的实测过程。回头看这类项目最大的价值不在于功能多炫而在于它是一条覆盖了“移动端、服务端、数据存储、对象存储”的完整链路。你会在开发过程中接触到微信登录的完整闭环、视频直传的性能取舍、Feed流的缓存设计、互动数据的一致性这些非常实战的问题这些才是项目真正值钱的地方。如果你正在准备做一个类似的系统我的建议是不要追求堆功能先把核心的短视频播放链路做通再逐步叠加社交模块和Feed流策略。过程中遇到问题不要硬扛善用后端日志和微信开发者工具的调试器大部分问题都能很快定位。后面我还会整理一套这个项目的核心接口定义和数据库表结构包括完整的API文档和建表SQL继续在这里更新。有任何关于这个系统的问题欢迎随时交流。