毕业设计选题又撞了如果你今年还在纠结“做一个简单商城”或者“仿一个社区 App”这个基于鸿蒙系统的小红书类项目完全可以换一个方向。它不是普通的前端静态页面而是使用 ArkTS 原生开发的应用端同时包含社交笔记、电商商城和 Web 后台管理是一套前后端完整的毕业设计项目。这个项目最值得关注的不是 UI 有多花哨而是它把“内容社区 交易闭环 管理后台”三个模块串在了一起。从用户发布笔记、浏览商品到后台审核内容和订单管理整条业务链路是通的。对于想拿鸿蒙生态做毕设、又不想只写“待办事项 App”的同学来说这套结构比单纯做一个商城或笔记应用更有说服力。本文会带读者完成三件事第一梳理项目拆分和技术选型搞清楚鸿蒙端、Web 后台、数据库之间怎么协作第二走一遍集成部署思路从 DevEco Studio 工程导入到后台服务启动再到模拟器登录验证第三列出最容易卡住的坑比如 ArkTS 权限申请、网络请求跨域、瀑布流数据刷新、后台接口返回格式不一致等问题。适合的读者主要有两类一是正在选毕设题目、想用鸿蒙原生开发做完整系统的同学二是想从 ArkTS 语法进阶到完整 App 开发、需要一套可运行源码作为参考的开发者。1. 项目定位与核心能力速览从项目标题来看这是一个仿小红书类应用但范围比“笔记社区”更大。它的核心组成是三块鸿蒙端 App基于 ArkTS 和 ArkUI 声明式 UI 开发的社交笔记 电商商城。Web 后台面向管理员的内容管理、用户管理、商品与订单管理。数据服务App 和后台共用一套业务接口与数据库。能力项说明项目类型HarmonyOS 原生应用 Web 管理后台开发语言ArkTS / ArkUI应用端Web 后台技术栈以源码实际交付为准核心功能社交笔记发布与浏览、用户互动、商品展示、购物车、订单、后台管理开发工具DevEco Studio需配套 HarmonyOS SDK运行设备DevEco 模拟器或鸿蒙真机具体兼容版本以源码配置为准数据存储服务端数据库推荐 MySQL端侧可使用 Preferences 做本地缓存是否需要联网需要App 与后台接口通过 HTTP 通信适合场景毕业设计、鸿蒙开发学习、作品集项目需要说明的是标题中的“源码可拿”意味着这套项目大概率是完整交付但 Web 后台具体用什么框架不同版本源码会有差异。常见毕设项目里后端用 Spring Boot MyBatis 或 Node.js Express 都比较常见拿到源码后第一件事就是核对后端启动方式和接口文档不要假设它一定是你熟悉的那个技术栈。2. 适用场景与使用边界这个项目适合用来完成毕业设计尤其是“鸿蒙系统 移动应用开发 前后端分离”这类选题。它比单纯的前端 Demo 强在业务链完整比大型企业级项目又更适合本科阶段在一学期内做完。但它并不适合直接当作商用产品上线。原因很简单一是仿小红书类界面涉及原产品的 UI 布局和品牌元素商用会有版权和商标风险二是商城功能如果接入真实支付必须走合法支付渠道和平台审核毕设阶段不需要也没有必要做真实资金流。使用边界也必须明确。这个项目涉及用户生成内容笔记发布、评论、用户昵称头像这些模块在演示和答辩阶段要使用自行构造的测试数据不能抓取或搬运真实平台的用户数据、图片和文案。涉及用户隐私的部分比如手机号、收货地址、登录凭证需要在后台做脱敏和最小化存储。涉及肖像的内容比如用户上传的头像和图片要确保来源合法、有授权不能随意下载网络图片用于演示。从毕设合规角度看建议在项目 README 和答辩 PPT 里写清楚这是学习用途的原型系统数据均为模拟数据交易为演示流程不涉及真实支付和真实用户信息。这样既保护自己也避免答辩时被追问数据来源。3. 开发环境准备与前置条件3.1 DevEco Studio 与 HarmonyOS SDK鸿蒙端开发必须使用 DevEco Studio。安装完成后需要启动 SDK Manager 下载对应版本的 HarmonyOS SDK。这里要特别提醒不同 DevEco Studio 版本自带的 SDK 版本不一样如果项目源码里的build-profile.json5配置的compileSdkVersion和本地 SDK 不一致导入工程时经常会出现编译失败。检查项建议DevEco Studio使用稳定版尽量与源码作者一致HarmonyOS SDK安装后先确认 compileSdkVersion 是否匹配签名配置真机调试需要配置签名模拟器调试要求较低hvigor 版本工程自带的 hvigor 配置不建议随意升级如果之前没有配过签名可以先在模拟器上跑通项目再考虑真机。真机调试需要在 AppGallery Connect 或 DevEco Studio 中完成签名配置这一步比 Android 开发要严格一些。3.2 模拟器与真机的选择鸿蒙项目不能直接丢进 Android 模拟器跑。推荐先用 DevEco Studio 自带的模拟器启动优点是环境一致、不占真机、不需要签名。缺点是模拟器对图片加载和视频播放的性能不如真机。如果要验证相机拍照、相册选图、定位这类硬件相关功能建议直接上鸿蒙真机。基于测试的便利性考虑图片上传和声音播放这类功能在模拟器上也可以完成但表现会和真机有差别。3.3 Web 后台运行环境Web 后台需要单独准备运行环境。不同源码差异较大常见有两种情况若使用 Spring Boot需要 JDK 和 Maven数据库用 MySQL。若使用 Node.js需要安装对应 Node 版本执行npm install安装依赖。数据库方面一般会提供初始化 SQL 脚本。拿到源码后先建库、导入脚本、修改数据库连接配置再启动后台服务最后测试接口。顺序不要颠倒否则 App 端只会看到网络错误或空列表。3.4 ArkTS 权限申请配置鸿蒙应用的权限声明在module.json5文件里访问网络等敏感权限必须在这里注册。项目开发中常见的权限配置如下{ module: { name: entry, type: entry, requestPermissions: [ { name: ohos.permission.INTERNET }, { name: ohos.permission.GET_NETWORK_INFO }, { name: ohos.permission.READ_MEDIA }, { name: ohos.permission.CAMERA } ] } }其中ohos.permission.INTERNET是网络请求必需权限。如果 App 打开后请求后台接口一直失败优先检查这个权限是否声明。部分权限还需要在代码里动态申请不能只写在配置文件中。4. 项目结构与工程拆分4.1 鸿蒙应用工程结构鸿蒙工程的根目录通常包含AppScope和entry模块。entry是应用入口模块核心代码位于entry/src/main/ets目录下。entry/src/main/ets/ ├── entryability/ │ └── EntryAbility.ets ├── pages/ │ ├── Index.ets │ ├── LoginPage.ets │ ├── NoteListPage.ets │ └── ProductDetailPage.ets ├── components/ │ ├── NoteCard.ets │ ├── ProductCard.ets │ └── CommentList.ets ├── api/ │ ├── request.ts │ ├── noteApi.ts │ └── orderApi.ts ├── model/ │ ├── NoteModel.ts │ ├── ProductModel.ts │ └── UserModel.ts └── utils/ └── StorageUtil.ts这不是固定模板而是比较合理的分层方式。pages放页面components放可复用组件api放网络请求层model放数据模型utils放工具类。拿到源码后先看目录结构基本就能判断作者的组织水平。4.2 Web 管理后台结构Web 后台无论用什么框架核心模块都围绕管理需求展开用户管理查看用户列表、禁用或启用账号。笔记管理审核笔记、下架违规内容。商品管理新增商品、修改库存、上下架。订单管理查看订单、修改订单状态。数据概览用户数、笔记数、订单量的统计图表。后台与前台的接口可以共用一套后端服务也可以独立部署。毕设项目中大多数是共用一套后端只是角色和权限不同。管理员账号登录后返回的 Token会标记为管理员角色接口层据此决定是否放行操作。4.3 数据模型设计核心数据表至少包括用户表、笔记表、评论表、收藏表、商品表、购物车表、订单表。以笔记表为例关键字段包括笔记 ID、用户 ID、标题、正文、图片列表、标签、发布时间、状态。商品表还需要包含标题、描述、价格、库存、图片、上下架状态。订单表要注意订单状态字段一般用整型或枚举字符串表示待付款、已付款、已发货、已完成、已取消。毕设答辩时数据库设计最先被追问建议把所有表的关联关系画清楚并解释为什么通过用户 ID 关联而不是在每张表里都冗余用户昵称。5. 鸿蒙端核心模块实现思路5.1 ArkTS 页面状态管理与导航ArkTS 在 ArkUI 框架下页面使用Entry和Component声明组件内部使用State管理私有状态。子组件之间可以通过Prop和Link传递数据跨页面传参建议使用路由参数。Entry Component struct NoteListPage { State noteList: NoteItem[] [] State loading: boolean false private pageIndex: number 1 aboutToAppear(): void { this.loadNotes() } async loadNotes(): Promisevoid { this.loading true try { const result await getNoteList(this.pageIndex, 10) this.noteList result.data } finally { this.loading false } } build() { Column() { List({ space: 12 }) { ForEach(this.noteList, (item: NoteItem) { ListItem() { NoteCard({ note: item }) } }, (item: NoteItem) item.id) } } .width(100%) .height(100%) } }这段代码展示了典型的页面结构aboutToAppear中加载数据List渲染列表NoteCard是自定义组件。实际项目中如果要实现小红书那种双列瀑布流可以将List换成WaterFlow但WaterFlow对数据变更的刷新机制需要单独处理建议先跑通接口再优化 UI。5.2 社交笔记模块社交笔记是这个项目最有辨识度的模块包含四个核心子功能笔记流首页展示推荐笔记双列瀑布流展示封面图。发布笔记支持填写标题、正文选择图片并上传。互动功能点赞、评论、收藏、关注作者。个人主页查看自己发布的笔记、收藏列表、粉丝与关注列表。发布笔记时图片上传是关键。App 先请求后台获取上传凭证或直接上传到静态资源目录后台返回图片 URLApp 再把正文和图片 URL 列表提交给新增笔记接口。如果接口设计不合理比如上传图片和创建笔记是分开的两步那么用户中途退出就会产生大量无用图片后台要定期清理。点赞和收藏功能建议使用独立表而不是在笔记表中加字段。虽然加like_count字段展示更快但用户是否点赞过需要单独判断。更稳的方案是建立note_like表记录“谁在什么时间点赞了哪条笔记”展示数量时查表求 count只在数据量变大后再考虑缓存。5.3 用户登录与 Token 管理App 登录后后台返回 Token客户端需要保存并在后续请求中带上。ArkTS 端可以使用持久化存储来保存登录状态。import { preferences } from kit.ArkData const PREF_NAME app_user export async function saveToken(token: string): Promisevoid { const store await preferences.getPreferences(getContext(), PREF_NAME) await store.put(token, token) await store.flush() } export async function getToken(): Promisestring | null { const store await preferences.getPreferences(getContext(), PREF_NAME) return store.getSync(token, ) as string }需要提醒的是Token 有有效期。如果后台返回 401App 不能只是弹一个“登录失败”而应该跳转到登录页清空本地 Token引导用户重新登录。很多毕设项目在这里做得不够完整答辩时被问“Token 失效了怎么办”就答不上来。5.4 电商商城模块商城模块围绕商品和订单展开。商品列表支持分类筛选、关键字搜索、分页加载。商品详情页展示轮播图、价格、库存和商品参数。购物车页面需要支持多选、修改数量、计算总价。订单确认页则需要选择收货地址并提交订单。这里有一个重要的设计决策购物车数据是保存在本地还是后台。如果只保存在本地换设备购物车就丢失如果保存在后台需要登录后才能操作。更稳妥的方式是购物车使用服务端存储App 端只负责展示和用户操作。毕设演示时可以提前往后台录几条测试商品避免现场网络波动导致商品图片加载失败。商城模块在答辩时会被追问“支付流程怎么设计”。建议回答原型系统中使用模拟支付订单状态由用户点击按钮触发变更只要状态机设计清楚即可。要强调生产环境必须接入正规支付渠道并满足平台审核要求。5.5 本地缓存与体验优化笔记列表和商品列表不适合每次进入页面都重新请求。可以在请求成功后把数据写入本地缓存下次进入先展示缓存再请求刷新。ArkTS 端可以简单使用preferences数据量更大时再考虑关系型数据库。同时要注意列表分页的常见问题上拉加载更多时不能直接覆盖列表要在原有数组后面追加下拉刷新时要重置页码重新请求第一页。如果这两个逻辑写反就会出现滚动到第二页后刷新第二页数据还留在数组里的 bug。6. Web 后台功能与数据管理6.1 后台功能拆分Web 后台的业务比 App 端更集中在“管理操作”上。管理员的登录与注册逻辑与 App 用户不同建议单独建管理员表或者用role字段区分用户角色避免用户越权访问管理接口。后台界面建议采用左侧菜单栏 右侧内容区的布局菜单项包括数据概览、用户管理、笔记管理、商品管理、订单管理、评论管理等。表格操作区要包含搜索框、筛选条件和操作按钮。整体设计不需要写得很复杂但交互链路要完整管理员要能对任意一条笔记执行下架操作。6.2 接口分层设计后台和 App 共用后端但要区分接口权限。推荐将接口按模块划分模块接口路径方法说明登录/api/loginPOST用户登录返回 Token笔记列表/api/notesGET分页获取笔记支持按分类筛选发布笔记/api/notesPOST创建新笔记需要登录点赞评论/api/notes/{id}/likePOST点赞或取消点赞商品列表/api/productsGET分页获取商品购物车/api/cartGET/POST查看与添加购物车创建订单/api/ordersPOST提交订单后台审核/api/admin/notesPUT管理员审核笔记需要管理员权限这里的路径只是参考具体字段以源码为准。但接口命名风格可以保持一致统一前缀/api资源名用复数动作尽量用 HTTP 方法区分。这样答辩时讲接口设计会更有章法。6.3 后台界面常见选型Web 后台常见选型是 Vue Element Plus或者 React Ant Design。毕设项目中用 Vue 的比较多因为上手快、中文资料多、增删改查表格组件现成。如果源码中的后台是前后端分离那么启动时要同时启动后端服务和前端工程。前端工程启动后访问一个本地开发端口后端提供 API 端口跨域问题需要后端开启 CORS 或在开发环境下配置代理。如果启动后界面能打开但表格里没有数据先按 F12 打开浏览器控制台看接口请求是不是跨域失败。7. 前后端接口与数据通信7.1 统一响应结构前后端分离的项目接口返回格式必须统一。推荐使用{ code, message, data }结构。code为 0 时表示成功非 0 表示失败message用于提示data携带业务数据。{ code: 0, message: success, data: { list: [], total: 0, page: 1, pageSize: 10 } }统一响应结构的好处是App 端可以封装一个统一的请求处理函数只判断code不需要为每个接口单独写错误分支。这个设计在代码评审和答辩中都是加分项。7.2 鸿蒙端网络请求封装鸿蒙端使用ohos.net.http发起 HTTP 请求。为了避免每个页面都写一遍请求可以在api/request.ts里封装一个通用函数。import http from ohos.net.http import { getToken } from ../utils/StorageUtil const BASE_URL http://192.168.1.100:8080 export interface ApiResponseT { code: number message: string data: T } export function requestT( path: string, method: http.RequestMethod, body?: object ): PromiseApiResponseT { return new Promise(async (resolve, reject) { const httpRequest http.createHttp() const token await getToken() const options: http.HttpRequestOptions { method: method, header: { Content-Type: application/json, Authorization: token ? Bearer ${token} : }, connectTimeout: 10000, readTimeout: 10000 } if (body) { options.extraData JSON.stringify(body) } httpRequest.request(BASE_URL path, options, (err, data) { if (err) { reject(err) return } const result JSON.parse(data.result as string) as ApiResponseT resolve(result) httpRequest.destroy() }) }) }这里需要注意两点BASE_URL要根据实际环境修改。在模拟器里宿主机访问地址可能与真机不同最稳妥的做法是把 Base URL 放到一个集中配置文件里避免全局搜索替换。Authorization头不是所有后台都叫这个名字有些后台用token字段需要按源码实际约定调整。7.3 图片上传与静态资源访问商品图片、笔记图片和用户头像都需要图片上传接口。上传时 App 端拿到图片后传给后台后台保存到服务器本地目录并返回可访问的 URL。毕设项目演示时最容易出现的问题有两个一是后台返回的是相对路径App 端拼 URL 时拼错二是图片上传成功但访问时 404一般是因为静态资源映射没有配置。如果启动后台后所有接口正常但图片打不开优先排查静态资源目录配置。8. 部署运行与功能验证8.1 启动顺序推荐按以下顺序启动整套系统启动数据库服务导入初始化 SQL。修改后台服务数据库连接配置。启动后台服务验证后台接口是否可访问。启动 Web 管理后台前端用管理员账号登录。在 DevEco Studio 中打开鸿蒙工程等待同步完成。启动模拟器或连接真机运行 App。8.2 冒烟测试清单第一次跑通项目时不建议逐页细看优先跑通主链路。下面是一份冒烟测试清单测试项操作步骤预期结果用户注册登录注册新账号退出后重新登录登录成功Token 写入本地笔记列表进入首页查看笔记流能加载后台已有笔记数据发布笔记输入标题和正文选择一个图片上传发布成功后台中出现新笔记点赞收藏在笔记详情页点赞收藏笔记状态更新刷新后仍保持商品列表进入商城模块查看商品列表能加载后台商品数据购物车添加商品修改数量计算总价购物车数据正确订单流程提交订单后台模拟发货订单状态流转正确后台审核后台下架一条笔记App 端该笔记不再展示权限控制用普通用户调用管理员接口返回无权限不会越权跑完这份清单核心功能基本就验证完毕。如果某一步卡住先看后台日志再看 App 的请求日志定位问题出在接口、数据还是页面上。8.3 演示数据准备答辩演示前一定要准备演示数据。建议在后台录入 8 到 10 条笔记、6 到 8 个商品、2 到 3 个用户账号每个账号有不同的发布记录。演示时不要现场注册新账号再慢慢发笔记浪费时间也容易出错。真正的演示重点应放在业务闭环上登录进入首页看笔记流点进详情看评论与点赞进入商城完成一次模拟下单再切到后台审核和订单管理。9. 常见问题与排查方法问题现象可能原因排查方式解决方案工程导入后编译报错SDK 版本不一致查看 build-profile.json5 与本地 SDK调整 compileSdkVersion 或安装对应 SDK模拟器打开后页面空白页面路由或数据为空查看日志是否请求报错检查接口地址和网络权限请求接口一直失败未声明 INTERNET 权限检查 module.json5添加权限配置登录返回 401Token 过期或没传查看请求 Header重新登录检查 Header 参数名后台接口返回跨域错误后台未配置 CORS打开浏览器控制台后端允许跨域来源图片加载失败静态资源映射缺失直接访问图片 URL配置静态资源目录上拉加载后重复数据分页逻辑错误查看页码是否递增重置页码或使用追加方式数据清理删除用户后关联数据未处理检查外键字段使用逻辑删除或级联处理还有一个容易被忽略的问题端口占用。后台服务启动时提示端口占用先查看占用进程换一个端口。如果改变了后台端口App 端的 Base URL 也要同步修改否则就会出现 App 能打开但数据拉不下来的情况。10. 毕设答辩与后续扩展建议这个项目最值得拿出来讲的是“技术选型”鸿蒙生态在当前环境里本身就是差异化亮点。答辩时不需要把代码逐行讲完重点讲三点一是为什么用 ArkTS 原生开发而不是 Web 套壳二是内容社区和商城的业务闭环怎么设计三是权限安全怎么处理包括用户登录、Token 校验、内容审核和接口越权防护。容易被动追的坑也要提前想好。比如“你这个 App 和真实小红书有什么区别”不要回答“功能一样”而是说这是学习型原型系统重点在 ArkTS 组件化设计和前后端完整链路UI 布局参考了主流内容社区的交互模式但不涉及真实平台的数据和品牌资源。再比如“支付功能怎么实现”需要强调演示流程使用模拟订单不涉及真实资金生产环境要对接正规支付渠道并符合平台规范。后续扩展可以从四个方向考虑。第一接入更多 HarmonyOS 特色能力比如原子化服务、一多适配、卡片服务第二增加内容推荐逻辑根据用户点赞和收藏记录做简单的兴趣标签推荐第三完善后台数据统计用图表展示用户增长和订单趋势第四把消息通知模块做成站内信或推送服务。这些方向任何一个在毕设答辩中都能展开讲也说明你不是只会照着源码抄页面。拿到源码之后第一步不是看界面而是先把后端数据库初始化跑通再启动后台最后用模拟器登录 App 完成一次“发布笔记 - 后台审核 - 商城下单 - 订单管理”的闭环。把这条链路走通这个毕设就立住了。建议收藏备用也可以直接作为鸿蒙开发入门到实战的参考项目。