企业官网建设流程全解析

最近不少朋友在准备毕业设计或项目实战时，都盯上了“校园短视频”这个方向。说实话，用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做token，code是一次性的，必须由后端换取真实身份信息后再自定义token。

校园身份绑定我放在登录之后，通过/auth/bind-campus接口完成。用户提交学校、学院、学号、姓名，后端校验学号格式（不同学校的学号规则不同，可以用正则做基本校验），绑定后用户主页展示校园信息。这块的核心价值是内容流的同校属性，所以我给User模型加了campus_id字段，后续Feed流可以按这个字段做内容过滤。

2.3 视频上传链路：从直传到转码

视频上传是整个系统里最容易出问题的环节，没有之一。我最终采用的是“小程序端直传对象存储”的方案，而不是“小程序先传后端再转存对象存储”的方案。

两种方案的区别在于：直传方案是后端先生成上传凭证（比如对象存储的临时密钥或签名URL），小程序拿到凭证后直接把视频上传对象存储，上传完成后再通知后端“我传完了，这是我的视频信息”。中转方案则是小程序把视频先传到后端服务器，后端再转存对象存储，等于视频流经了你的Web服务。

中转方案的优点是代码简单，小程序端只调后端一个接口就行，但代价非常大。你的后端带宽会成为瓶颈，视频上传耗时成倍增加，而且后端服务器存储压力、流量费用都会暴涨。如果多个用户同时上传视频，后端服务直接可能卡死。所以只要对象存储支持直传，一定要用直传方案。

我当时的完整上传流程是：

1. 小程序端请求POST /video/upload-token，传入视频大小和类型。
2. 后端校验用户登录态，生成并返回上传凭证（有效期设置短一点，比如10分钟）。
3. 小程序拿到凭证后直接把视频文件传到对象存储，同时手动指定一个object名称，一般是userId_timestamp.mp4这种格式。
4. 上传成功后，小程序调POST /video/create接口，传视频标题、描述、封面地址、视频地址、校园话题ID等元数据。
5. 后端在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缓存方案在答辩里绝对是个加分项。

评论列表返回时，还需要返回评论者的头像、昵称信息。这里要避免N+1查询问题，也就是循环查每个评论的作者信息。正确做法是先用评论文本关联出所有user_id，一次性IN查询所有用户信息，然后内存里做关联拼接。N+1问题在短视频系统里特别容易暴露，因为首页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的临时密钥方式，签名算法需要小程序端自行计算，这对毕设不友好。更省事的方式是用后端的预签名URL（PUT方式直传），小程序端通过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 高频问题速查表

我在开发调试的过程中，把遇到的高频问题整理成了一张速查表，每一条都是实操后的结论。

5.2 实战避坑笔记

除了表格里那些技术问题，还有几个开发过程中的经验想分享一下。

第一个是环境问题。开发阶段一定要把小程序后台的“不校验合法域名”打开，否则本地联调时所有请求都会被拦截，很容易误判成后端写错。但上线前务必关闭这个选项，并且把后端域名、对象存储域名全部配置到合法域名列表中。这个流程很多人到了上线环节才发现，临时被卡住一两周。

第二个是用户身份问题。不要在前端存储openid，更不要把openid作为用户标识展示在页面上。openid是微信生态里的敏感身份标识，正确做法是后端维护自己的user_id，小程序端只操作这个user_id。涉及校园信息的展示也要脱敏，学号中间部分打码显示。

第三个是关于微信平台的能力限制。小程序发布视频不代表可以无限制使用所有API。像wx.chooseMedia的相机拍摄能力是完整的，但如果有涉及直播或特定内容类目，平台对类目要求很严格。项目的功能设计和答辩内容要控制在不触碰平台类目限制的范围内。

第四个是部署层面的经验。后端不要部署在本地电脑上让人用局域网访问，这样演示时一旦断网或电脑休眠整个系统就挂了。更稳妥的方式是部署到一台云服务器上（阿里云或腾讯云的学生机即可），配置好HTTPS证书，小程序端请求走HTTPS，这样真机预览也能直接访问，演示效果会好很多。

最后一个我认为非常重要的经验是备份。数据库和对象存储里的内容要定期备份，开发过程中经历过对象存储误删文件、数据库被跑崩的意外。不要觉得毕设项目不需要备份，开发到后期如果本地代码或数据库丢了，心态真的会崩。

写在最后

这篇文章里的所有经验，都来自我完整开发一个校园短视频系统的实测过程。回头看，这类项目最大的价值不在于功能多炫，而在于它是一条覆盖了“移动端、服务端、数据存储、对象存储”的完整链路。你会在开发过程中接触到微信登录的完整闭环、视频直传的性能取舍、Feed流的缓存设计、互动数据的一致性这些非常实战的问题，这些才是项目真正值钱的地方。

如果你正在准备做一个类似的系统，我的建议是不要追求堆功能，先把核心的短视频播放链路做通，再逐步叠加社交模块和Feed流策略。过程中遇到问题不要硬扛，善用后端日志和微信开发者工具的调试器，大部分问题都能很快定位。

后面我还会整理一套这个项目的核心接口定义和数据库表结构，包括完整的API文档和建表SQL，继续在这里更新。有任何关于这个系统的问题，欢迎随时交流。