企业官网建设流程全解析

简介：这份资源是面向高校计算机相关专业学生的课程设计参考资料，主题为网上校友通讯系统，适合正在完成数据库或信息系统课程设计、需要完整项目文档与程序清单的学习者。压缩包内共1个doc文件，约1.18MB，内容涵盖课程设计成绩评定表、摘要、目录及正文，完整呈现从需求分析到物理设计的开发流程。文档详细记录了调查用户需求、绘制数据流图与数据字典、设计分E-R图与总E-R图、将E-R图转换为关系数据库模型，以及关系优化、视图、存储过程、函数等性能优化手段，并附有程序清单可供参考。目前已有367人学习下载，读者可借此掌握信息系统开发全过程的文档撰写规范与数据库建模思路，理解校友信息存储、通讯管理与在线留言等核心功能的实现逻辑，适合作为课程设计报告撰写与项目答辩的实用范本。

1. 从一份 .doc 说起：校友通讯系统课程设计到底要交付什么

如果你手里正躺着一个名为「网上校友通讯系统课程设计(附程序清单).doc」的文件，或者导师刚把这个题目甩给你，那你大概率正卡在同一个地方：知道要做个系统，但不知道从哪下手、做到什么程度算合格、程序清单里到底该放什么。这个标题拆开看其实包含三件事——一个能跑的校友通讯系统、一份讲得清的设计文档、一份能让人照着复现的程序清单。它解决的核心问题是：把散落在各届班级里的校友信息，用一套增删改查加检索的 Web 系统管起来，让管理员能维护、普通校友能查询。适合的人群很明确：计算机相关专业做课程设计的学生，以及需要快速搭一个信息管理类 Demo 的初级开发者。别把它想成社交平台，它的本质是一个带权限的通讯录管理系统，想清楚这一点，后面所有选型和代码都会顺很多。

2. 需求拆解与数据库设计：校友通讯系统的表结构怎么定

动手写代码之前，先把需求和数据模型定死，这是整个课程设计里最容易被低估、也最容易返工的一步。校友通讯系统的业务看着简单，但字段设计一旦拍脑袋，后面查询、导出、权限全得推倒重来。

2.1 先分清三类角色和它们各自要干什么

任何信息管理系统，第一步都是把「谁用、用来干嘛」列清楚。校友通讯系统通常有三类角色：系统管理员、班级管理员（或者叫联络员）、普通校友。管理员负责账号和全局数据，班级管理员维护本班信息，普通校友只能查和改自己的资料。这个划分直接决定了后面表里要不要放角色字段、权限判断写在哪一层。

我一般会先在纸上画一张角色-功能对照表，把每个角色能点的按钮列出来，再反推需要哪些接口。常见做法是：

这张表不是给别人看的，是给你自己写 SQL 和接口时当 checklist 用的。很多同学做到一半发现「普通校友居然能删别人」，就是因为一开始没把权限落到字段上。

2.2 核心表结构与字段取舍

校友通讯系统的数据库不用搞复杂，四张表基本够用：用户表、校友信息表、班级表、日志表（可选）。下面给出一个可以直接用的 MySQL 建表脚本，字段命名和类型都是我踩过坑之后收敛下来的版本。

-- 班级表：先建，被校友表引用 CREATE TABLE class_info ( class_id INT PRIMARY KEY AUTO_INCREMENT, class_name VARCHAR(64) NOT NULL COMMENT '如 计算机0801', grade_year SMALLINT NOT NULL COMMENT '入学年份', counselor VARCHAR(32) COMMENT '辅导员姓名' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 用户表：登录与权限 CREATE TABLE sys_user ( user_id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE, password CHAR(64) NOT NULL COMMENT '存 SHA-256 摘要，不存明文', role TINYINT NOT NULL DEFAULT 3 COMMENT '1管理员 2班级管理员 3校友', class_id INT COMMENT '班级管理员和校友归属班级', status TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 0禁用', FOREIGN KEY (class_id) REFERENCES class_info(class_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 校友信息表：业务主体 CREATE TABLE alumni ( alumni_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT UNIQUE COMMENT '关联登录账号', real_name VARCHAR(32) NOT NULL, gender TINYINT DEFAULT 0, phone VARCHAR(20), email VARCHAR(64), company VARCHAR(128), position VARCHAR(64), city VARCHAR(32), update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES sys_user(user_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

逻辑说明：班级表独立出来是为了避免「班级名」在校友表里反复冗余，改一次班级名要更新几百行。用户表和校友信息表拆开，是因为登录凭证和业务资料的生命周期不同——账号可能被禁用，但校友资料要保留。密码字段用 CHAR(64) 存 SHA-256 摘要，这是最低要求，明文存密码在课程设计答辩时是硬伤。

参数说明：utf8mb4而不是utf8，因为校友姓名里可能有生僻字，utf8三字节存不下，这个坑我在真实项目里翻过车。grade_year用 SMALLINT 而不是 VARCHAR，方便按届检索和排序。update_time用ON UPDATE CURRENT_TIMESTAMP，省得每次更新都在代码里手动写时间。

2.3 索引和查询场景要对上

表建完别急着写 Java 或 Python，先想清楚最频繁的查询是什么。校友通讯系统里最高频的三个查询是：按姓名模糊搜、按班级列、按城市筛。对应加索引：

-- 姓名模糊查询用前缀匹配才能走索引，所以查询时用 '张%' 而不是 '%张%' CREATE INDEX idx_alumni_name ON alumni(real_name); -- 按班级查，走 user 表的 class_id CREATE INDEX idx_user_class ON sys_user(class_id); -- 按城市筛 CREATE INDEX idx_alumni_city ON alumni(city);

这里有个血泪经验：LIKE '%张%'这种前后都带通配符的写法，索引直接失效，数据量上千就开始卡。课程设计数据量小感觉不出来，但答辩老师一问「你怎么优化的」就露馅了。正确做法是引导用户输入姓氏做前缀匹配，或者上全文索引。数据库增删改查这四个字说起来简单，真正拉开差距的就是这些细节。

3. 后端接口与程序清单：从登录到通讯录查询的最小实现

数据库定好之后，进入编码阶段。这一章给出一套能跑通的最小后端实现，语言用 Java（课程设计里最常见），思路换成 Python Flask 或 Node 也完全一样。程序清单不是把代码堆上去就完事，而是要让读的人明白每个类为什么存在。

3.1 分层结构与程序清单该放哪些文件

一个合格的课程设计程序清单，应该能让人看出你的工程结构，而不是一堆散文件。我一般按这个目录组织：

src/ ├── dao/ 数据访问层，一个表一个类 │ ├── UserDao.java │ └── AlumniDao.java ├── service/ 业务逻辑层，处理权限和校验 │ ├── AuthService.java │ └── AlumniService.java ├── controller/ 接口层，接收请求返回 JSON │ ├── LoginServlet.java │ └── AlumniServlet.java ├── model/ 实体类，和表字段一一对应 │ ├── User.java │ └── Alumni.java └── util/ └── DBUtil.java 数据库连接与关闭

程序清单里至少要包含这四层各自的代表文件，外加一个DBUtil。别把所有逻辑塞进一个 Servlet，答辩时老师一眼就能看出你是不是抄的。

3.2 登录与权限校验的关键代码

登录是整个系统的入口，也是权限的起点。下面这段是AuthService的核心逻辑，重点看密码校验和角色判断。

public class AuthService { private UserDao userDao = new UserDao(); // 返回登录用户，失败返回 null public User login(String username, String rawPassword) { User user = userDao.findByUsername(username); if (user == null) { return null; // 用户不存在，不提示具体原因，防枚举 } if (user.getStatus() == 0) { return null; // 账号被禁用 } // 对明文做 SHA-256 后与库中摘要比对 String digest = DigestUtils.sha256Hex(rawPassword); if (!digest.equals(user.getPassword())) { return null; } return user; } // 判断当前用户能否操作目标班级的数据 public boolean canManageClass(User current, int targetClassId) { if (current.getRole() == 1) { return true; // 系统管理员放行 } if (current.getRole() == 2) { return current.getClassId() == targetClassId; } return false; // 普通校友无管理权限 } }

逻辑说明：登录失败统一返回 null，不区分「用户不存在」和「密码错误」，这是防止账号枚举的基本操作。canManageClass把权限判断收敛到一个方法里，所有涉及班级数据的操作都调它，避免权限逻辑散落各处导致漏判。

参数说明：DigestUtils.sha256Hex来自 commons-codec，课程设计里够用；真实项目应该加盐并用 bcrypt。role的取值 1/2/3 要和数据库注释保持一致，别一边写 1 是管理员一边代码里判断 0。

3.3 通讯录查询接口与分页

校友列表是使用频率最高的功能，必须分页，否则数据一多页面直接卡死。下面给出查询方法，包含按姓名、班级、城市三个条件的动态拼接。

public List<Alumni> search(String name, Integer classId, String city, int page, int size) { StringBuilder sql = new StringBuilder( "SELECT a.*, u.class_id FROM alumni a " + "JOIN sys_user u ON a.user_id = u.user_id WHERE 1=1 "); List<Object> params = new ArrayList<>(); if (name != null && !name.isEmpty()) { sql.append("AND a.real_name LIKE ? "); params.add(name + "%"); // 前缀匹配，能走索引 } if (classId != null) { sql.append("AND u.class_id = ? "); params.add(classId); } if (city != null && !city.isEmpty()) { sql.append("AND a.city = ? "); params.add(city); } sql.append("ORDER BY a.update_time DESC LIMIT ? OFFSET ?"); params.add(size); params.add((page - 1) * size); return jdbcTemplate.query(sql.toString(), params.toArray(), new AlumniRowMapper()); }

逻辑说明：用WHERE 1=1起头是为了后面每个条件都能无脑AND，不用判断是不是第一个条件。所有参数走占位符?，杜绝 SQL 注入，这是课程设计里必须体现的安全意识。LIMIT ? OFFSET ?实现分页，OFFSET用(page-1)*size算。

参数说明：name + "%"是前缀匹配，配合第 2 章建的索引才有效；如果写成"%" + name + "%"索引失效。size建议固定 10 或 20，别让前端随便传，否则有人传 10000 直接把库拖垮。ORDER BY update_time DESC让最近更新的排前面，符合通讯录的使用直觉。

3.4 前端页面与接口对接的最小闭环

后端接口通了，前端不用花哨，一个列表页加一个搜索框就能交差。用原生 HTML + fetch 即可，重点是理解请求怎么发、数据怎么渲染。

// 加载校友列表，page 从 1 开始 async function loadAlumni(page = 1) { const name = document.getElementById('searchName').value; const url = `/alumni/search?name=${encodeURIComponent(name)}&page=${page}&size=10`; const resp = await fetch(url); const data = await resp.json(); const tbody = document.querySelector('#alumniTable tbody'); tbody.innerHTML = ''; data.list.forEach(item => { const tr = document.createElement('tr'); // 用 textContent 赋值，避免 XSS tr.innerHTML = `<td></td><td></td><td></td><td></td>`; tr.children[0].textContent = item.realName; tr.children[1].textContent = item.phone || '-'; tr.children[2].textContent = item.company || '-'; tr.children[3].textContent = item.city || '-'; tbody.appendChild(tr); }); }

逻辑说明：encodeURIComponent处理中文姓名，否则搜索「张」可能因为编码问题查不到。渲染时用textContent而不是直接拼innerHTML，防止校友姓名里带特殊字符造成 XSS，这是很多课程设计忽略的点。

参数说明：page默认 1，size固定 10 和后端约定一致。返回结构约定为{list: [], total: n}，方便后面加分页控件。

4. 避坑与排查：课程设计里最容易翻车的五个地方

代码能跑不代表没问题，下面这五条是我见过最多的翻车现场，每条都按「现象 → 原因 → 解决」说清楚。

4.1 中文乱码：查出来的姓名全是问号

现象：数据库里存的中文正常，但页面上显示成???或者乱码。 原因：三个环节的字符集没统一——数据库连接串没指定编码、表用了utf8存不下生僻字、Tomcat 或响应头没设 UTF-8。 解决：连接串加?useUnicode=true&characterEncoding=utf8mb4，建表统一utf8mb4，响应头设Content-Type: text/html;charset=UTF-8。三处缺一不可，只改一处照样乱码。

4.2 密码明文存储：答辩一问就慌

现象：数据库里密码字段一眼能看出是123456。 原因：图省事直接存了明文，或者只在注册时加密、登录时忘了同样处理。 解决：注册和登录都走同一个摘要方法，存和比对用同一套逻辑。别一个用 MD5 一个用 SHA-256，自己给自己挖坑。

4.3 分页参数被恶意放大：一次请求拖垮数据库

现象：有人手动把 URL 里的size改成 100000，页面卡死。 原因：后端直接信任前端传来的分页参数，没做上限校验。 解决：在 Service 层强制size = Math.min(size, 50)，page小于 1 时归 1。参数校验是后端的责任，不能指望前端老实。

4.4 外键约束导致删班级失败

现象：想删一个班级，报外键约束错误，删不掉。 原因：sys_user表里有记录引用了这个class_id，InnoDB 默认阻止删除。 解决：要么先处理关联用户（改班级或删用户），要么把外键设为ON DELETE SET NULL。课程设计里建议先查清楚有多少关联数据，别硬删。

4.5 连接池没关：跑一会儿就报连接超时

现象：系统用一会儿就报Too many connections或连接超时。 原因：每次数据库操作都新建连接，用完没关，连接数只增不减。 解决：用DBUtil统一管理连接的获取和关闭，放在finally块里关。或者直接上 Druid、HikariCP 连接池，配置最大连接数。数据库连接池这个概念在课程设计里提一句，答辩能加分。

5. 进阶技巧：把课程设计做成能写进简历的项目

课程设计如果只满足于「能跑」，那它就是一个作业；如果多想一步，它能变成你简历上拿得出手的项目。这一章讲几个投入不大但效果明显的进阶点。

5.1 加一个数据导出功能，成本低但很实用

校友通讯录最常见的真实需求是导出成 Excel 发给老师或用于活动通知。用 Apache POI 几十行就能实现，比任何花哨功能都实用。

// 导出全部校友到 Excel public void exportToExcel(List<Alumni> list, OutputStream out) throws IOException { try (Workbook wb = new XSSFWorkbook()) { Sheet sheet = wb.createSheet("校友通讯录"); String[] headers = {"姓名", "性别", "电话", "邮箱", "公司", "职位", "城市"}; Row head = sheet.createRow(0); for (int i = 0; i < headers.length; i++) { head.createCell(i).setCellValue(headers[i]); } int rowIdx = 1; for (Alumni a : list) { Row row = sheet.createRow(rowIdx++); row.createCell(0).setCellValue(a.getRealName()); row.createCell(1).setCellValue(a.getGender() == 1 ? "男" : "女"); row.createCell(2).setCellValue(a.getPhone() == null ? "" : a.getPhone()); row.createCell(3).setCellValue(a.getEmail() == null ? "" : a.getEmail()); row.createCell(4).setCellValue(a.getCompany() == null ? "" : a.getCompany()); row.createCell(5).setCellValue(a.getPosition() == null ? "" : a.getPosition()); row.createCell(6).setCellValue(a.getCity() == null ? "" : a.getCity()); } wb.write(out); } }

逻辑说明：用 try-with-resources 保证 Workbook 自动关闭，避免内存泄漏。表头单独一行，数据从第二行开始。每个可能为 null 的字段都做了空值处理，否则 POI 会抛 NPE。

参数说明：XSSFWorkbook对应.xlsx格式，数据量大时用SXSSFWorkbook流式写。导出接口记得设响应头Content-Disposition: attachment; filename=alumni.xlsx，否则浏览器直接打开而不是下载。

5.2 用日志表记录关键操作，答辩时是亮点

加一张操作日志表，记录谁在什么时候改了什么，实现简单但显得专业。

CREATE TABLE op_log ( log_id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id INT, action VARCHAR(32) COMMENT 'LOGIN/UPDATE/DELETE', target VARCHAR(64) COMMENT '操作对象，如 alumni:12', ip VARCHAR(45), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

在 Service 的关键方法里插一条日志即可。答辩老师问「怎么追溯数据被谁改了」，这张表就是答案。

5.3 验证方法：怎么证明你的系统真的能用

别自己点两下就说完成了。我一般用三个动作验证：第一，造 500 条测试数据，看分页和搜索是否还流畅；第二，用两个不同角色的账号登录，确认普通校友看不到管理按钮、也调不动管理接口；第三，故意输入单引号和<script>，确认没有 SQL 注入和 XSS。这三步走完，系统才算真的立住了。

5.4 一个具体技巧：把配置抽到文件里

数据库地址、账号、密码别硬编码在 Java 里，抽到db.properties：

jdbc.url=jdbc:mysql://localhost:3306/alumni_db?useUnicode=true&characterEncoding=utf8mb4 jdbc.username=root jdbc.password=your_password jdbc.driver=com.mysql.cj.jdbc.Driver

换环境只改这个文件，代码一行不动。这个习惯从课程设计开始养成，工作后能省掉无数麻烦。

最后说个我自己的教训：当年做课程设计，我把所有逻辑塞进一个类，答辩时老师让我改一个查询条件，我找了十分钟才定位到。后来我强迫自己分层、写注释、把配置抽出去，代码才真正变成能维护的东西。课程设计不是交差，是你第一次完整走一遍工程流程的机会，认真对待它，它会回报你。希望帮到你。

本文还有配套的精品资源，点击获取