HTML消息推送系统毕设怎么做？开题与技术选型全攻略

很多同学一到开题季就容易陷入一个怪圈：手里捏着一个题目，比如“基于HTML的消息推送系统”，第一反应是“这题太水了”“HTML能做什么推送”或者“到处都有现成代码，我还能写什么”。但实际带过项目、审过开题报告的人都知道，这类题目恰恰是最能拉开差距的。题目字面看起来简单，但里面藏着前端工程化、服务端通信协议、接口设计、浏览器兼容性一整串问题，任何一个环节想深入都能写出一篇有分量的论文。

这篇内容就针对这个题目，把“从拿题到开题”这一整条路捋一遍。我会拆解题目背后的真实需求、对比主流的消息推送技术路线，再把我预研阶段写过的三个Demo思路放出来供参考，最后聊聊开题报告每一节该怎么填、答辩时导师最可能问什么。不管你最后是打算用纯原生JavaScript还是Vue这类框架，看完至少不会再对着开题报告空白页发愁。

1. 先把这个题目彻底拆明白

1.1 “基于HTML”到底指什么

先解决一个最容易被问住的问题：这个题目的主角到底是HTML还是消息推送？说句实话，如果开题答辩时你说“本系统使用HTML做前端”，导师大概率会当场追问一句“HTML是标记语言，不具备逻辑处理能力，你的系统逻辑写在哪里”。所以千万不要把“基于HTML”理解成“用HTML写一个系统”，这既做不到，也不是题目本意。

结合毕业生常见的课题命名习惯，“基于HTML的消息推送系统”更准确的翻译是：以HTML技术栈作为前端承载，构建一套能够在浏览器端向用户主动推送通知消息的Web应用系统。HTML在这里代表的是终端形态和展示层，真正干活的是JavaScript、后端服务、消息通信协议这三样东西。系统能做什么、长什么样子由HTML/CSS决定，数据怎么到达浏览器则靠通信方案决定。

想明白这一点，开题报告的“研究内容”才写得出来。你要研究的是两个层面，一是浏览器端如何使用标准化的页面结构、样式和脚本搭建消息展示与用户交互界面；二是后端产生消息之后，如何实时或准实时地让浏览器页面感知到变化并完成展示。这两件事合起来，才是题目的完整内涵。

1.2 开题报告的一页纸逻辑

很多同学把开题报告当成任务书来写，堆了一整页背景、意义、国内外现状，最后连自己“具体做哪几件事”都说不清楚。其实开题报告如果压缩成一页纸，逻辑就是四句话：

• 目前消息通知依赖用户反复刷新或第三方软件，存在信息滞后和体验割裂的问题。
• 本课题基于HTML技术构建一个免安装、跨平台的Web消息推送系统，重点解决消息从“用户主动查”变成“服务端主动送”。
• 系统将完成通知管理、实时推送、历史记录与前端展示等模块。
• 采用前端原生技术加后端推送服务的技术路线，在浏览器端实现消息即时触达。

不要小看这四句话，它是所有章节的骨架。我见过太多开题报告“研究内容”写了八条，每一条互相重叠，一看就知道作者没有想清楚系统的边界。你只需要围绕“消息从哪来、消息怎么送到浏览器、浏览器怎么展示通知、用户怎么处理已读未读”这四个问题去展开，课题范围就非常清晰，后续工作量也好估算。

2. 技术路线怎么选

2.1 消息推送本质是“谁主动找谁”

要理解消息推送的几种技术方案，先想清楚一个朴素的场景：你在电脑前挂着后台页面，别人给你发了一条审批消息，这条消息是怎么出现在你屏幕上的？消息从服务端到浏览器，本质上只有两条路：浏览器主动去问，或者服务端主动来送。

浏览器主动去问，叫轮询，实现最简单，但服务端什么时候有消息你并不知道，只能固定间隔反复询问，存在明显的延迟和无效请求。服务端主动来送，则需要浏览器和服务端之间先建立一条可以持久保持的连接，让服务端在任意时刻都能把数据推给浏览器，这才是真正意义上的Push。两者之间的取舍，构成了整个系统技术选型的核心矛盾：实时性要求高不高，连接数规模大不大，服务端资源允许多少空闲连接。

开题报告里最好能用术语把这条思考线写明，比如把“用户主动查”对应成拉模式，把“服务端主动送”对应成推模式，然后说明本课题重点研究的是推模式及其在Web环境下的实现限制。这样一来，导师能一眼看出你对问题本质是有理解的，而不是只会抄需求。

2.2 三种推送方案横向对比

先给出结论：目前能在浏览器端做消息推送的成熟方案主要有三种，短轮询、服务端发送事件（SSE）、WebSocket。各有各的适用面，不要在开题阶段就迷信某个方案，而是要根据你的课题目标来选。

短轮询：前端用JavaScript的定时器每隔几秒请求一次后端接口，查询是否有新消息。优点是兼容性极好、开发成本低，缺点是实时性有限且会产生大量无效请求。如果后台页面很多，这种方案会给服务器带来不必要的压力。

SSE（Server-Sent Events）：浏览器通过EventSource接口与服务器建立一个HTTP长连接，服务器可以随时向浏览器推送文本格式数据。优点是使用简单、自动重连、基于HTTP协议，适合单向推送场景，比如通知、新闻、股票行情。但它是单向通道，客户端如果想给服务端发消息，还得另外走普通请求。

WebSocket：通过一次HTTP升级握手建立全双工长连接，客户端和服务端可以互相发送数据，适合聊天、协同编辑这类强交互场景。缺点是协议相对复杂，需要处理连接保活、断线重连、心跳机制，部署到Nginx时需要额外配置升级头。

为了在开题报告里讲得更直观，我通常会做一张方案对比表放进“技术路线”一节，让数据说话：

做完这个表，你会在开题报告中写下类似表述：“考虑到本系统核心场景是平台向用户发送通知消息，消息方向以服务端到客户端为主，技术上优先考虑采用……”。这句话就是整篇技术选型的主心骨，可以明显看出你的判断力。

2.3 我推荐的技术组合

如果现在有人拿着这个题目来问我预研建议，我最推荐的技术组合是：前端HTML5 + CSS3 + JavaScript（或Vue 3）+ 后端Node.js（Express），消息通信用WebSocket，另加一个REST风格的HTTP接口处理登录、已读、历史记录等普通操作。

为什么补一个REST接口？因为消息推送系统不只是推送，还需要管理。用户进入系统后要拉取未读消息列表、确认已读、删除消息，这些动作都属于低频请求，没有必要都走WebSocket。走普通接口更简单，也方便做权限校验和日志记录。而新的消息则由服务端在业务事件发生时通过WebSocket连接主动推给在线用户。这样做的好处是两种通道各管一摊，职责清晰，后续写论文时每个模块的作用也容易描述。

有人可能会问，既然WebSocket最适合，为什么还要研究SSE和短轮询？这里要回答开题报告里的“研究意义”：把三种方案做进同一个系统做实测对比，本身就是有意义的毕设工作。比如你可以在预研阶段分别读取100条、500条、1000条消息，测一测服务端内存占用和浏览器端渲染耗时，然后给出结论。这种对比实验的结论放进论文里，比照抄一篇技术博客有价值得多。

3. 系统模块设计与数据流转

3.1 用“用户故事”定边界

开题阶段最容易犯的错是功能膨胀，今天想加短信提醒，明天想加APP推送，后天又想做多租户。我的建议是先把项目的核心用户故事写出来，功能边界自然会收紧。

以“基于HTML的消息推送系统”为例，核心用户故事按优先级排列大概是这几条：管理员登录后台后，可以填写消息标题和内容，选择接收人后发布消息；普通用户打开消息中心页面后，能看到实时的未读消息，新消息到达时页面顶部弹出提示；用户点击某条消息后，系统将该条标记为已读，消息列表数字减少；系统保留用户最近七天的历史消息，方便用户回溯。

你会发现这几个故事完全够支撑一个能演示的毕设系统了。推送、消息列表、已读未读、历史记录、用户管理，五个功能形成闭环。如果你愿意，可以再加一条“离线时消息重新上线后补发”，方案是利用离线期间记录的消息表，在用户重新建立连接时查询未读并一次性推给前端，这一条正好能把“服务端推送失败如何处理”的问题引出来，答辩时有话说。

3.2 功能模块切分成四块

结合上面的用户故事，系统功能可以切分成四个核心模块，每个模块都能对应到开题报告中的“系统功能结构图”：

通知管理模块，负责消息的创建、编辑、定时发送和接收人选择。前端提供表单页面，后端将消息写入MySQL或者其他关系型数据库的消息表。

连接管理模块，负责维护服务端与浏览器的WebSocket连接，记录每个用户对应的连接ID。用户登录后建立连接，退出页面后销毁连接。这个模块是整个系统的技术难点，涉及连接表设计、心跳检测、断线清理。

推送与消费模块，负责在消息发布后找到所有符合条件的用户连接，逐个执行推送动作。推送成功后写入用户维度的消息状态表，默认未读。如果用户不在线，则只写状态表，等待用户下次上线触发查询。

前端展示模块，负责消息实时提醒、未读角标、消息列表、详情查看、标记已读等界面交互。这里体现HTML/CSS/JavaScript的核心工作量，也是论文截图的重要来源。

模块划分的逻辑要经得起追问：为什么消息表要冗余到每个用户？如果一张通知表存公共消息、一张用户消息表存每个用户的已读状态，那么当一条消息同时发给很多人时，只需要在通知表中存一份正文，用户消息表中存多条“已读状态”即可。这就是典型的一对多关系建模，开题时这些细节提到即可，不用写太深，但思路要清晰。

3.3 前端界面与交互设计方案

前端是整个系统“看得见”的部分，也是“基于HTML”这个题眼最直接的证明。建议提前把页面结构和交互设计在开题报告里列出来，至少应包括四个页面：登录页、消息中心列表页、消息详情页、管理员发布消息页。

视觉风格不要花哨，但一定要完整，整套界面建议采用左右分栏后台布局：左侧是导航栏，显示“消息中心”“已读历史”“发布通知”等入口，右侧是内容区。技术实现上可以用原生CSS的Flex或Grid完成布局，不需要引入重型UI框架，但为了演示效果，也可以用Vue加上Element Plus等现成的组件库，减少手写样式的时间。

交互层面的设计更关键，新消息到达时怎样提示？我建议做三档提示：浏览器标签页标题闪烁；页面右上角弹出一个小型通知卡片，2秒后自动消失；侧边栏未读数字加一。这三档几乎覆盖了所有用户注意力的场景，而且每一档都能用HTML/CSS/JavaScript独立实现，串起来就是一个很不错的系统亮点。答辩时可以让导师现场给另一个浏览器发一条消息，这种实时效果带来的观感远胜于PPT里的十页描述。

4. 预研阶段写过的三个Demo

4.1 Demo 1：用AJAX轮询先把链路跑通

不管最后选不选择轮询方案，我建议预研的第一步都先做一个“笨”版本，目的是把前后端数据链路跑通，排除环境问题。当时我用Node.js写了一个极简接口，每调用一次就从消息表里取出最新一条消息返回。

后端核心代码大致长这样：

javascript复制const express = require('express');
const app = express();

// 模拟消息数据
let latestMessage = {
    id: 1,
    title: '系统测试',
    content: '这是一条来自服务端的轮询消息',
    createTime: Date.now()
};

app.get('/api/poll', (req, res) => {
    res.json({
        code: 0,
        data: latestMessage
    });
});

app.listen(3000, () => {
    console.log('server running at http://localhost:3000');
});

前端页面用原生JavaScript的setInterval发起请求，拿到新消息后创建一个DOM节点插入列表。真正的问题是间隔设为多少合适，我一开始设了1秒，打开浏览器控制台一看Network面板，一秒一个请求，接口还没做缓存，服务端日志一行接一行往外刷。如果页面再开几个标签页，这种写法显然撑不住。

所以Demo 2的SSE方案很快就被我提上日程，它会从根本上减少无意义的请求。

4.2 Demo 2：用SSE实现简化的服务端推送

SSE的好处是门禁低，不需要额外引入第三方库，浏览器内置EventSource对象，服务端只需要设置好响应头，把数据按固定格式写进响应流即可。

javascript复制const express = require('express');
const app = express();

app.get('/api/sse', (req, res) => {
    res.writeHead(200, {
        'Content-Type': 'text/event-stream',
        'Cache-Control': 'no-cache',
        'Connection': 'keep-alive',
        'Access-Control-Allow-Origin': '*'
    });

    // 每5秒推送一条更新
    const timer = setInterval(() => {
        res.write(`data: ${JSON.stringify({ time: Date.now(), message: 'SSE最新通知' })}\n\n`);
    }, 5000);

    req.on('close', () => {
        clearInterval(timer);
        res.end();
    });
});

app.listen(3000);

前端只需要两行核心代码：

javascript复制const source = new EventSource('http://localhost:3000/api/sse');
source.onmessage = function (event) {
    const data = JSON.parse(event.data);
    document.getElementById('latestMessage').innerHTML = data.message;
};

体验下来确实比轮询顺滑不少，服务端不需要每次重新创建HTTP响应，连接建立后一路推到底。如果你想加一个指定接收人的功能，只需要在事件流里带上userId字段，前端判断当前登录用户是不是接收人，再决定是否展示。这已经有点真实系统雏形了。

SSE还有一个容易被忽略但很实用的特性：内置自动重连。如果网络抖动导致连接断开，浏览器会默认重连，这对毕设系统来说省去很多麻烦。代码里不需要额外处理断线逻辑，这一点当年让我省了不少事。

4.3 Demo 3：用WebSocket把双向通道打通

完整版的推送系统最终选用了WebSocket，原因很简单：系统里除了服务端给用户推消息，用户还要给服务端发送“标记已读”“获取历史列表”等指令。虽然这些指令可以用HTTP接口处理，但统一收口到一条WebSocket通道会让前端逻辑更清爽，尤其是当用户连续操作多条消息时，可以省下大量手写回调的代码。

先看服务端，我用的Node.js加ws模块：

javascript复制const WebSocket = require('ws');
const server = require('http').createServer();
const wss = new WebSocket.Server({ server });

// 用一个Map保存用户id到连接对象的映射
const clients = new Map();

wss.on('connection', (ws, req) => {
    // 真实环境中userId应该从token解析，这里演示直接从URL取
    const userId = new URL(req.url, 'http://localhost').searchParams.get('userId');

    if (userId) {
        clients.set(userId, ws);
    }

    ws.on('message', (message) => {
        const data = JSON.parse(message);
        if (data.type === 'markRead') {
            // 实际项目这里要操作数据库，演示仅做日志输出
            console.log(`用户${userId}把消息${data.messageId}标记为已读`);
        }
    });

    ws.on('close', () => {
        clients.delete(userId);
    });
});

setInterval(() => {
    // 每10秒向在线用户推送一条测试通知
    const testMsg = JSON.stringify({
        type: 'notice',
        content: '模拟的新通知：' + Date.now()
    });

    clients.forEach((client) => {
        if (client.readyState === WebSocket.OPEN) {
            client.send(testMsg);
        }
    });
}, 10000);

server.listen(8080);

前端建立连接和接收消息的代码也很直接：

javascript复制const ws = new WebSocket('ws://localhost:8080?userId=1001');

ws.onopen = function () {
    console.log('连接已建立');
};

ws.onmessage = function (event) {
    const data = JSON.parse(event.data);
    if (data.type === 'notice') {
        // 更新页面上的未读消息卡片
        appendMessage(data);
    }
};

function appendMessage(data) {
    const box = document.getElementById('notice-box');
    const div = document.createElement('div');
    div.className = 'notice-item';
    div.innerHTML = `<span>${data.content}</span>`;
    box.prepend(div);
}

这个Demo让我理解了两个核心要点：第一，WebSocket连接需要在登录后主动建立，不能像普通HTTP接口那样每次请求带token就完事，必须自己处理连接生命周期；第二，连接表一定要设计好，我一开始把连接对象挂到一个全局数组，用户断开后没有及时清除，结果内存占用越来越高，改成Map、在close事件里删除连接后才稳定下来。

4.4 三条路线的最终取舍

三个Demo做完，我的选型结论已经非常清楚了：系统最终采用WebSocket作为主消息通道，因为核心场景对实时性有要求，同时需要支持前端发起的反馈指令，双工通信能省去很多设计上的别扭。但SSE也不会被完全丢弃，当服务端需要批量广播一些系统公告时，SSE的轻量特性反而比WebSocket更合适，代码里只需要维护一个长期连接。

如果开题答辩时导师问“你只研究WebSocket，为什么还要做另外两个Demo”，你可以这样回答：比较是研究方法的一部分，通过三个方案的实测对比，能够明确各自在连接建立时间、消息到达延迟、服务端资源占用上的表现差异，从而为系统技术选型提供数据支撑。这个回答比“WebSocket比较流行”有力得多。

5. 开题报告正文与答辩问答准备

5.1 一篇合格开题报告的章节骨架

写开题报告时，建议按以下顺序组织，每一个章节都有明确目标，不要简单复制粘贴模板：

选题背景与研究意义，重点写当前Web应用通知交互的不足，说明本课题的价值，控制在600字左右即可。国内外研究现状，从浏览器实时通信技术演进聊起，最初是靠Flash与插件，后来发展到Comet、长轮询，再到HTML5标准下的WebSocket和SSE，让每个技术点之间形成脉络，而不是流水账。研究内容与关键问题，列出要实现的四个模块，明确系统的核心难点是“连接管理”和“离线补发”，这是导师最关注的部分。技术路线与系统方案，给出系统架构图、功能模块图和流程图，并配上技术选型对比表格。预期成果与论文结构，写清楚你最终交付一个怎样的系统，论文涵盖哪几章。进度安排，按周划分，预留两周左右的测试和缓冲期。

这里提醒一下，不要为了凑字数把重点放在研究现状上。我发现很多开题报告的研究现状写得像读书笔记，把国外学者的文献一篇篇罗列，却说不清跟自己的题目有什么关系。本科毕设更看重的是你能否在一个可控范围内把工程做扎实，所以在开题中把“研究内容”和“技术方案”写详细，比把“研究现状”写得满天飞要实用得多。

5.2 技术路线图不依赖工具也能画清楚

技术路线图很多人误以为必须用特定绘图工具，其实用画图软件画也可以，但要保证出现在报告里的图信息准确、逻辑清楚。系统架构图至少要画三层：浏览器端（HTML页面、JavaScript）、服务端（HTTP接口、WebSocket服务）、数据层（MySQL消息表、用户表、已读表）。用文字来描述也可以很直观，但正式报告还是建议用简洁的矩形框加箭头表示，别把图表做成一团毛线。

画图时有个容易忽略的逻辑顺序：先画业务流程，再画系统架构，最后画核心模块流程图。业务流程侧重描述“管理员发消息、用户收消息、用户标记已读”的过程；系统架构侧重说明技术组件之间的调用关系；核心模块流程图则把“消息如何从数据库走到浏览器页面”的每一步标清楚。三张图各有分工，不要画成同一件事的重复表达。

5.3 答辩高频问题清单

每个导师的提问风格不同，但下面几个问题几乎每个项目都会被问到：

• 你的系统和QQ群通知、微信模板消息有什么区别？你的优势在哪里？
• 如果同时有500个浏览器在线，你的WebSocket服务端会不会崩，如何验证？
• 用户关闭浏览器后，消息是怎么存储的？重新登录后还能不能收到？
• 消息推送一定实时吗？如果网络发生抖动导致连接断开，你的方案如何处理？
• 前端页面如何保证新消息提醒不会打扰到用户？你有没有设计免打扰时段？

这些问题每一个都能在功能设计里找到映射，但想回答得漂亮，必须在预研阶段做过真实测验。比如500个浏览器在线这个问题，你不需要真开500个浏览器，写一个简单的Node.js压测脚本创建500个WebSocket客户端连接，观察服务端CPU和内存变化，把结果写在开题报告的预期成果里，答辩时直接报出数据，比你空口说“可以支持”强太多。

6. 预研阶段踩过的坑与排查办法

6.1 浏览器层面的坑

调试时最容易遇到的是跨域问题。我用Express跑在3000端口，前端页面用Vite开发服务器跑在5173端口，两边端口不同，浏览器会拦截请求。解决办法是在Express后端手动设置跨域响应头，或者引入cors中间件，一行代码就能解决。

另一个容易困惑的是浏览器对后台标签页的节能机制。Chrome为了省电，如果页面处于后台，setInterval的定时器会被降频甚至暂停。这意味着轮询方案在用户切换到其他标签页时，消息提醒可能会变得不准确。实际测试中1秒间隔能拉到几分钟，第一次遇到时我还以为是后端挂了，后来查了文档才发现是这个坑。

6.2 服务端与网络层的坑

部署阶段最经典的问题就是WebSocket连不上。本地开发时一切正常，部署到云服务器后前端一直报握手失败。排查下来两个原因：一是Nginx没有配置WebSocket转发所需的Upgrade和Connection请求头，默认情况下Nginx只做HTTP转发，升级请求直接被丢弃；二是后端服务开的端口没有在安全组放行，TCP连接根本到不了服务端。

对应的Nginx配置片段大概是这样：

nginx复制location /ws/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
}

另外，如果网站本身用的是HTTPS，WebSocket也要用wss://，否则会被浏览器当成混合内容拦截，这个错误在控制台里经常被误认为后端问题，白白浪费很多时间。

6.3 快速验证实时效果的土办法

调试WebSocket推送给在线用户时，有时候手头没有现成的测试客户端，我习惯用网页自带控制台直接模拟，也可以是另一个浏览器开着一个页面，然后通过后端的接口手动触发一次推送，观察前端展示是否更新。更贴近真实场景的是，我自己写了一个几十行的辅助脚本，每隔几秒自动调用发布接口。打开两个浏览器窗口，一个作为管理员登录，另一个作为用户登录，看用户侧是否弹出新消息，这个办法虽然没有自动化测试那么专业，但用来演示和找bug非常直观。

如果未来要扩展，还可以给系统增加消息模板、定时发布、未读消息红点动画、消息声音提醒等功能。核心思路是在现有WebSocket技术上增加业务复杂度和视觉效果，具体功能放在交付期看个人时间再定。说到底，毕设不是一个展示你技术有多宽的修罗场，而是一个把一个点做深、把每个决策讲明白的练习场。

从拿到题目到写完开题报告，我最大的体会是：千万别沉迷“工具技巧”，一定要先把“你解决什么问题、用什么方式解决、凭什么这样选”这三句话说清。能把这三句话讲通，开题报告就已经成功了一大半，后面的系统实现只是按图索骥、逐步填充细节。