企业官网建设流程全解析

如果你的毕业设计选题又撞了，想看鸿蒙系统方向，又不想只做一个简单的应用，基于鸿蒙系统 + ArkTS 原生开发的小红书风格 APP 项目可以重点了解。它把社交笔记、电商商城和 Web 后台放进同一个方案里，APP 端用 ArkTS 原生开发，后台负责内容与商品管理，整体源码可以拿来做二次开发，比单独做一个登录页加列表页的毕设要完整得多。

这类项目的价值不只是“小红书”这个产品形态，而是它同时覆盖了移动端、服务端和 PC 管理端。对毕设来说，最难的不是单个页面写得多炫，而是几条业务链路能完整跑通。下面从选题、环境、核心功能、ArkTS 开发细节、源码改法和答辩准备这几个角度拆一遍。

1. 为什么选择“鸿蒙系统 + ArkTS + 小红书式社交电商”

1.1 毕设选题撞车，撞的其实是复杂度不够

很多毕设选题撞车，不是题目完全一样，而是做出来的东西同质化严重。最常见的三种模式是：图书管理系统、课程管理系统、商品管理系统。这些项目的重点几乎全在增删改查，页面结构简单，数据表也就那么几张，答辩时很难体现工作量。

换成鸿蒙系统方向后，技术栈本身就比较新。如果再选择“仿小红书”这种内容社交产品，模型会丰富很多：用户信息、笔记内容、图片、点赞、收藏、评论、关注关系、商品、购物车、订单，每一块都能单独展开讲。老师看到的不是一个“管理系统”，而是一个有实际业务形态的 APP。

当然，选这个题目不是告诉老师“我做了个小红书”，而是要说清楚自己的工程结构。建议把项目拆成三块：鸿蒙 APP 端、Web 管理后台、后端服务接口。三块加在一起，复杂度足够支撑一个合格甚至偏优秀的毕设。

1.2 ArkTS 原生开发，比 H5 套壳更能讲出技术点

“仿小红书”有不少现成的 Web 版或 H5 套壳方案，但毕设用 H5 套壳很容易被老师追问一句：“你的原生能力体现在哪里？” 如果只是放了一个 WebView，再加载一个网页，那移动端的很多内容就讲不下去。

ArkTS 是鸿蒙系统原生应用开发的语言，底层配合 ArkUI 声明式 UI 框架，写起来类似 TypeScript 加现代声明式组件。它和传统 XML 布局或手动 findViewById 的方式不同，页面状态变了，界面会自动更新。对比下来，ArkTS 代码结构更清晰，适合在毕设里展示组件化思路。

更重要的是，ArkTS 可以做很多原生能力的事情。比如调用相机拍照、读取相册图片、申请权限、本地持久化、网络请求、设备信息获取等。这些在答辩时都可以演示，也能回答“你为什么用原生开发”的问题。

1.3 社交笔记和电商商城结合，业务链路更完整

如果只做内容社区，做完笔记发布和点赞评论就结束了，缺少交易链路。如果只做商城，又和普通电商项目没区别。把社交笔记和电商商城放在一起，能构成一条完整的用户行为路径：

用户浏览笔记 -> 看到关联商品 -> 进入商品详情 -> 加入购物车 -> 模拟下单 -> 后台看到新订单。

这样设计后，系统至少覆盖四类核心数据：用户、内容、商品、订单。每一类都要设计表结构、接口、页面和管理后台。对毕设来说，工作量很充裕，而且功能之间不是割裂的，演示时能串成一个故事。

2. 项目整体拆解：APP、Web后台、服务端各管什么

2.1 鸿蒙APP端：从内容消费到交易闭环

APP 端是用户直接操作的部分，建议按小红书常用的信息架构去规划页面。不需要刻意追求和真实产品一致，但功能上要成体系。

我会把 APP 端拆成这些模块：

• 首页笔记信息流：展示卡片式笔记，封面图、标题、作者、点赞数。
• 笔记详情页：展示完整图文内容，支持点赞、收藏、评论。
• 发布页：选择图片、填写标题和正文，可选关联商品。
• 发现页：标签分类、搜索入口、商品推荐位。
• 消息页：展示点赞、评论、关注通知，做列表即可。
• 我的页：个人信息、我的发布、我的收藏、订单入口。
• 商城页：商品列表、商品详情、购物车、结算下单。

这个页面的数量不算多，但每个页面都承担不同的业务职责。做的时候可以先按“列表页 -> 详情页 -> 操作页”去拆，不要一开始就追求很复杂的 UI，先把页面跳转和数据流跑通。

2.2 Web后台：内容管理、商品管理和订单处理

Web 后台是给管理员用的，主要解决内容审核和商品管理问题。互联网产品的内容一般都需要后台审核，这也是一个很好的答辩点。

后台建议包含以下几个页面：

• 登录页：管理员账号登录。
• 数据看板：展示用户数、笔记数、商品数、订单数、销售额。
• 内容审核：管理员查看笔记详情，通过或下架。
• 商品管理：商品新增、编辑、上架、下架。
• 订单管理：查看订单列表、修改订单状态。
• 用户管理：查看用户列表，禁用异常账号。

后台技术栈不限。如果你熟悉 Vue 或 React，直接选一个用过的框架做管理界面，配合表格、弹窗、表单组件，开发速度比较快。后端接口需要和 APP 端共用，不能后台一套接口，APP 又单独一套。

2.3 服务端和数据库：接口设计与数据模型

服务端是整个项目的中枢。APP 端所有数据都来自接口，Web 后台的审核和商品管理也依赖接口。所以接口要先划分清晰，再动手写页面。

接口建议按模块划分：

• 用户模块：注册、登录、获取用户信息、更新用户信息。
• 笔记模块：发布笔记、获取笔记列表、获取笔记详情、删除笔记、审核笔记。
• 互动模块：点赞、取消点赞、收藏、评论、获取评论列表。
• 关注模块：关注用户、取消关注、获取关注列表。
• 商品模块：商品列表、商品详情、商品上下架。
• 购物车模块：加入购物车、修改数量、删除购物车项。
• 订单模块：创建订单、订单列表、修改订单状态。

每个接口使用统一的返回结构，例如：

{ "code": 0, "message": "success", "data": {} }

前端根据 code 判断请求是否成功。如果 code 不是 0，就弹提示或跳登录。这样处理起来比每个接口单独返回不同字段要省事。

数据库核心表大致会有这些：用户表、笔记表、笔记图片表、评论表、点赞记录表、收藏记录表、关注关系表、商品表、商品分类表、购物车表、订单表、订单商品表。其中订单和订单商品要拆开，因为一个订单可能包含多个商品，如果不拆，后面统计销售额和明细会非常难受。

2.4 文件存储和部署

图片上传是这个项目绕不开的问题。用户发布笔记要传图片，商品也要图片。毕设阶段可以先把图片存到后端的本地目录，比如 upload 文件夹，通过静态资源访问。不上传对象存储也没关系，但要注意：

• 图片大小要限制，后端做大小和类型校验。
• 文件名最好用时间戳加随机数生成，避免重名。
• 列表页建议用缩略图，详情页再加载原图。

后端服务可以放在本机跑，数据库用 MySQL 或 PostgreSQL。部署到演示机器上的时候，端口固定下来，防火墙放行，手机和电脑尽量连同一个 WiFi，这样 APP 端才能通过局域网访问到后端接口。

3. 开发环境准备：从工具到真机，先把最小环境跑起来

3.1 必须准备的开发工具

先把环境准备好，再谈写代码。开发鸿蒙应用最核心的工具是 DevEco Studio，它是鸿蒙应用开发用的 IDE，创建工程、写 ArkTS 代码、查看日志、连接设备都在里面完成。

首次打开 DevEco Studio 后，一般会提示安装 HarmonyOS SDK。建议选择稳定版本，不要一上来就追最新版，因为新版 SDK 可能伴随签名策略、权限规则、API 接口的变化。只要工程能用，就先把开发流程跑通。如果标题或源码里写了目标 API 版本，优先用对应版本打开工程，避免升级后大量报错。

有些同学会纠结鸿蒙系统电脑版怎么安装。实际上毕设开发的核心并不是电脑版系统，而是 DevEco Studio 加模拟器或真机。开发调试用模拟器就够了，涉及相机、相册、定位等系统能力时，再换真机验证。

3.2 创建工程和配置权限：ArkTS 权限申请

新建工程时，语言选 ArkTS，模板选 Empty Ability。工程创建后，主要代码在 entry/src/main/ets 目录下，页面文件按功能模块拆分。

鸿蒙应用需要申请网络权限。如果源码里的请求总是失败，优先检查 module.json5 里有没有配置 INTERNET 权限。一个常见的权限配置示例：

"requestPermissions": [ { "name": "ohos.permission.INTERNET" } ]

这只是网络权限。如果发布笔记需要调用相机和相册，还要根据功能申请对应权限。不同 API 版本的权限写法会有差异，建议以你当前使用的 SDK 提示为准。第一次运行项目时，如果遇到权限弹窗，先确认是不是没有在配置文件里声明。

3.3 模拟器、真机和后端联调

模拟器适合快速调 UI，但相机、定位、扫码这类能力比较受限。真机调试需要开启开发者模式，连接电脑后让 DevEco Studio 识别设备。第一次真机运行通常需要登录华为账号并配置签名，这一步很容易卡住，但不是代码问题。

不要一开始就把后端地址写成 localhost。模拟器里是模拟器自己的网络环境，真机也有独立的 IP。比较稳妥的方式是：后端服务启动后监听 0.0.0.0，APP 里的接口地址改成电脑的局域网 IP，例如 http://192.168.1.100:8080。电脑和手机连同一个 WiFi，并检查防火墙是否放行对应端口。

如果接口地址写错，现象通常是页面加载不出来或请求超时。先看日志里有没有网络错误，再检查地址、端口、后端是否启动，三个点按顺序排查。

3.4 拿回源码后的目录阅读顺序

如果项目标题里提到“源码可拿”，拿回来之后不要急着点运行。先按顺序看几类文件：

1. README 或项目说明文档：环境要求、启动步骤、注意事项。
2. 数据库脚本：建表语句、初始数据、管理员账号。
3. 后端接口文档：每个模块的 URL、请求参数、返回结构。
4. APP 全局配置：接口 baseUrl、应用名、页面入口。
5. Web 后台配置：端口、接口地址、登录方式。

先花半小时理解目录结构，再启动数据库和后端，最后跑 APP。很多人拿回源码直接点运行，发现一堆报错，其实不是源码问题，而是环境没准备好。

4. 核心功能从 0 到 1 要怎么做：笔记、电商、后台的落地思路

4.1 先做“笔记信息流”作为最小闭环

不建议一上来就做全部功能。第一个目标应该是：APP 启动后，首页能显示后端返回的笔记列表。这个闭环跑通，等于把“前端请求 + 后端接口 + 数据库数据”整条链路打通了，后面加功能都会顺利很多。

笔记列表的数据结构可以简化成：id、title、author、coverUrl、likeCount。后端接口返回分页数据，APP 端用 ArkTS 定义一个模型类，再通过网络请求获取数据，用列表组件渲染。

一个简单的 ArkTS 卡片组件大概长这样：

@Component struct NoteCard { @Prop title: string; @Prop author: string; build() { Column({ space: 6 }) { Text(this.title) .fontSize(18) .fontWeight(FontWeight.Medium) Text('作者：' + this.author) .fontSize(13) .fontColor('#888') } .width('100%') .padding(12) .backgroundColor(Color.White) .borderRadius(12) .margin({ bottom: 10 }) } }

这只是示意。实际项目里会加上封面图、头像、点赞数，但思路是一样的：定义组件，接收数据，渲染 UI。

网络请求可以用鸿蒙提供的 HTTP 模块。示例代码如下：

import http from '@ohos.net.http'; function fetchNoteList(page: number, pageSize: number) { const httpRequest = http.createHttp(); httpRequest.request( 'http://192.168.x.x:8080/api/notes?page=' + page + '&pageSize=' + pageSize, { method: http.RequestMethod.GET, connectTimeout: 10000, readTimeout: 10000 } ).then((response) => { const result = JSON.parse(response.result as string); console.info(`code: ${result.code}, data size: ${result.data.length}`); }).catch((error) => { console.error(`request error: ${JSON.stringify(error)}`); }); }

这里的 IP 要换成实际后端地址。不要直接复制就跑，很多问题就出在地址和端口不一致。

4.2 发布笔记和互动功能

笔记信息流跑通后，再做发布。发布流程大概是：用户选择图片，填入标题和正文，点击发布，APP 调用上传接口，后端保存图片文件，同时把笔记记录写入数据库。

发布时要注意几个细节：

• 图片先压缩再上传，避免内存占用和传输超时。
• 后端接收文件时限制格式和大小，比如只允许 jpg、png，单张不超过 5MB。
• 发布成功后进入我的发布列表，能立刻看到新发布的笔记。

点赞、收藏、评论属于互动功能。接口设计比较简单，但前端交互要注意：点赞按钮不要点了就立刻改成红色，先等接口返回成功再改状态。如果网络失败，再恢复原状态并给用户提示。这样可以避免演示时出现“界面点了没变化”或“数据不一致”的情况。

4.3 电商模块：商品、购物车、订单

电商模块不需要做得很复杂，但订单这条链路要通。先做商品列表和商品详情，再购物车，最后下单。

商品列表可以参考笔记列表的做法。商品详情页主要有图片、标题、价格、库存、购买按钮。加入购物车时，前端调用购物车接口，传到后端的参数至少包含商品 id、数量、用户 id。购物车列表展示商品信息、价格、数量修改和删除。

提交订单时要考虑两个点：

• 订单和订单商品要分开建表。一个订单对应多个订单商品项。
• 创建订单时最好在后端校验商品库存，避免演示时出现负数库存。

订单状态可以简单设计成：待支付、已支付、已发货、已完成、已取消。毕设不接入真实支付也没问题，把“去支付”按钮做成模拟支付，点击后调用后端接口把状态改成已支付即可。

4.4 Web后台：先做内容审核和商品上下架

Web 后台的价值在于“可管理”。如果只有 APP，所有内容都直接入库，老师会问你“恶意内容怎么处理”。有了后台审核，整个闭环就完整了。

建议先做内容审核。后台管理员打开待审核笔记列表，看到笔记信息，点击通过或下架。业务不复杂，但能覆盖一个完整的管理场景。

商品管理类似，主要是商品表的增删改查。再加一个上下架状态，下架商品不能在 APP 端购买。只要字段设计和接口保持一致，后台和 APP 就能共用同一套服务端接口。

数据看板可以放在最后做。统计用户数、笔记数、订单数、销售额，SQL 用 count 和 sum 就能算出来。不要为了好看做过于复杂的图表，先把核心指标展示清楚。

5. ArkTS 开发中的关键细节：状态管理、网络请求和常见报错

5.1 状态管理怎么安排

ArkTS 声明式开发里，状态变化驱动 UI 更新。经常用到的装饰器有 @State、@Prop、@Link。

• @State：页面内部可变状态，比如列表数据、加载状态。
• @Prop：父组件传给子组件的只读数据，由父组件更新。
• @Link：父子组件双向绑定，修改会同步回去。

毕设项目大部分页面不需要引入复杂的全局状态管理。登录用户信息可以放在 AppStorage 或 PersistentStorage，页面跳转时再读取。购物车数量、未读消息这类公共数据，如果多个页面都要显示，再考虑放到公共位置。

不要把所有状态都堆在一个页面里。比如首页信息流数据、加载状态、错误提示、分页参数，这些应该集中在首页的 Entry 组件里管理，子组件只负责展示。这样排查问题时能很快定位。

5.2 网络请求和加载状态

网络请求最好封装成一个工具方法。每次请求前自动附加 token，返回 401 时统一处理跳转登录。如果每个页面都自己写一遍 http.request，很容易出现错误处理不一致。

一个简单的封装思路：

function request(url: string, method: http.RequestMethod, params?: object) { // 从存储里读取 token // 拼接请求头 // 发起请求 // 解析结果 // code 不等于 0 时统一提示 }

页面里只用调用 request，不用关心基础逻辑。

同时，列表页必须处理三种状态：加载中、加载成功有数据、加载失败或空数据。只写一个 loading 状态不够，还要考虑空列表时显示“暂无数据”，失败时显示“重新加载”。否则实际演示时，只要后端没启动，页面就是白屏。

5.3 图片处理、列表复用、分页

图片是内容类 APP 的核心资源，也是最容易出问题的地方。网络图片用 Image 组件加载，但大图直接加载容易造成内存上涨。通用做法是：列表页使用后端返回的缩略图 URL，详情页再加载完整图片。发布时客户端先压缩图片，再上传。

笔记列表数据量变大后，不要直接一次性把所有数据都加载完。每次请求传 page 和 pageSize，后端返回当前页数据和 total。前端在滚动到底部时触发下一页加载，并判断 hasMore 是否还有下一页。

列表渲染可以用 ForEach，简单直接。数据量较大时再用 LazyForEach，它可以按需创建组件，减少卡顿。如果是普通毕设，先保证数据和 UI 正确，不一定要追求极限性能。

5.4 常见问题排查链路

做鸿蒙项目时，遇到问题不要急着改代码。按照下面顺序排查：

1. 先看现象：是编译失败、运行闪退、白屏、网络报错，还是按钮没反应。
2. 再看日志：DevEco Studio 的 Log 面板会打印 ArkTS 侧的异常信息，很多崩溃原因能在日志里直接看到。
3. 再看配置：module.json5 权限、应用签名、API 版本、后端地址是否写对。
4. 再看输入：网络请求参数是否完整，JSON 字段是否和后端返回一致。
5. 再看工具：模拟器卡顿、真机未识别、端口被占用、IDE 版本和 SDK 不匹配。

比如应用在真机上安装不成功，优先看签名和设备版本。页面请求不到数据，优先看后端有没有启动、接口地址是不是 localhost、防火墙有没有放行端口。UI 显示异常，优先看组件结构和样式，不一定是数据问题。按这个顺序来，能少走很多弯路。

6. 拿到源码后怎么跑通、改造和演示

6.1 跑通顺序和验收标准

拿到源码后，建议按“数据库 -> 后端 -> Web后台 -> APP”的顺序跑。

先导入数据库脚本，确认表都建好，再启动后端服务，用接口工具测试登录和列表接口。后端接口通了，再启动 Web 后台，看后台登录和列表页面能不能拉取数据。最后启动鸿蒙工程，真机或模拟器安装，用测试账号登录。

每一步都有明确的验收标准：

• 数据库：SQL 脚本执行成功，没有报错。
• 后端：本地服务正常启动，接口能返回 JSON。
• Web 后台：管理员能登录，能看到首页数据。
• APP：首页能加载笔记列表，登录后能发布笔记，商城能下单。

如果哪一步卡住，默认是环境问题，不要怀疑“源码是不是坏了”。先看日志和配置，再找环境差异。

6.2 怎么改造成“自己的”毕业设计

直接拿源码提交毕设，风险很大。老师随便问一个字段或流程，答不上来就很容易露馅。更稳妥的方式是拿源码做底座，然后做出明显改造。

简单改造包括：

• 修改应用名称、应用图标、默认主题色。
• 把笔记字段从“标题 + 正文”扩展成“标题 + 分类 + 标签”。
• 增加一个“搜索笔记”功能，后端用 SQL 模糊查询。
• 把订单状态从五种改成四种，重新梳理状态流转。
• 给 Web 后台增加一个“批量审核”功能。

这些改动都不复杂，但能让项目看起来不完全一样。更重要的是，改造过程中你会真正理解代码结构，答辩时也更有底气。

6.3 答辩演示脚本，先讲场景再讲代码

答辩演示不要一上来就打开代码。先讲清楚业务场景，再演示功能，最后补充技术细节。

推荐按这个顺序演示：

1. 打开 Web 后台，展示数据看板，说明用户、内容、订单的数据规模。
2. 后台审核一篇刚发布的笔记。
3. 打开鸿蒙 APP，登录账号，首页看到已通过的笔记。
4. 点击笔记详情，点赞、收藏、评论。
5. 发布一条新笔记，上传图片，提示待审核。
6. 回到后台，看到新笔记并审核通过。
7. 回到 APP，刷新首页，看到自己刚发的笔记。
8. 进入商城，把商品加入购物车，模拟支付下单。
9. 打开后台订单管理，看到新订单。

一条线下来，社交内容和交易都覆盖了。演示完后，再打开代码结构，讲 APP 端 ArkTS 页面怎么拆、后端接口怎么设计、数据库表怎么关联。

6.4 可能被问到的问题，提前准备答案

老师可能会问几个角度的问题，提前准备会从容很多：

• 为什么用鸿蒙和 ArkTS？答：原生声明式 UI，能调用系统能力，生态正在发展。
• 登录态怎么做？答：后端返回 token，前端存储在本地，请求头带上。
• 点赞并发怎么处理？答：简化版是更新数字，不做复杂并行控制；进阶可以做唯一索引防止重复点赞。
• 图片存哪里？答：本地静态目录，正式环境可以换成对象存储。
• 订单状态如何流转？答：待支付 -> 已支付 -> 已发货 -> 已完成，取消操作要从待支付状态进入。
• 哪些模块是自己写的，哪些用了现成开源库？答：要把 UI 组件、HTTP 库、数据库框架说清楚，不要所有东西都说是自己从零写的。

6.5 如果还有时间，可以继续扩展

毕设交付后如果还有余力，可以再往下面几个方向扩展：

• 搜索功能：按标题、正文、作者搜索笔记。
• 个性化推荐：按标签权重或用户行为排序。
• 消息推送：鸿蒙系统的推送通知。
• 数据统计：后台用图表展示近七日新增用户和销售额。
• 多端适配：手机和平板使用不同布局。

这些扩展不会破坏现有结构，也能让项目在评审时更有亮点。但要注意，每一个扩展都要保证能跑通，不能只写代码不验证。稳定的基础功能，永远比一堆没跑通的“创新点”更重要。

最后留一个提醒：毕设项目真正落地时，最该盯住的不是功能列表写了多少，而是输入输出是否完整、接口是否稳定、演示流程是否顺畅。基于鸿蒙系统 + ArkTS 原生开发的小红书风格 APP，只要把笔记、电商、后台三块跑顺，已经是一个完成度很高的毕业设计。剩下的时间，多花在理解源码和准备答辩问答上，比盲目加功能更有价值。