企业官网建设流程全解析

很多做高校里的小型活动的辅导员、学生会干部，还有接毕业设计的学生，应该都有这种感觉：校园里的小活动特别多——讲座、比赛、社团招新、志愿活动、分享会，基本每周都有。但报名方式还停留在"填在线表格""群里接龙""让各班学委统计"这些原始阶段，统计起来费劲不说，还容易漏人、重报。我这次想聊的这套"高校校园微活动报名系统"，很直接，就是解决这类问题的：微信小程序端让学生发现活动、一键报名、查看自己的报名记录，后台由 PHP 框架撑起活动管理、人员统计、导出数据这些脏活。项目核心选型是 ThinkPHP 和 Laravel 两套框架，前后端分离，小程序走 API 接口。

这篇内容对应的是一份论文式的完整课题，我按实际做项目的顺序把思路从头到尾捋一遍。做这个东西的人，大概率是计算机相关专业的毕业生，也可能是在学校信息中心帮忙的开发者。写这篇东西的价值在于：这类"小程序 + PHP 后台"的项目是毕业设计里最经典的组合之一，但很多同学卡就卡在——需求分析一塌糊涂，数据库表乱设计，接口写得像草稿，最后代码拿不出手。我尽量把从需求到上线要踩的坑都讲清楚，能直接照着抄的那种。

1. 项目到底做什么，为什么我要用两个框架写一遍

1.1 一个容易被毕业设计忽略的"工作量锚点"

先说选题。论文题目里同时出现 ThinkPHP 和 Laravel，很多人第一反应是"这俩不是重复造轮子吗"。其实这正是毕业设计里常见的"策略性对比"思路：同一个业务系统，分别用 ThinkPHP 和 Laravel 各实现一遍后端接口，然后从开发效率、代码可维护性、性能表现、安全性这些维度做对比。这样论文的工作量一下就扎实了，评阅老师看到的不再是"一个简单 CRUD"，而是有工程对比、有实测数据的完整研究。

这么做的实际好处也不只是应付论文。ThinkPHP 在国内中小型项目里受众很广，Laravel 是国际 PHP 社区的主流标准，两套框架都跑通一遍，你对路由、中间件、ORM、服务容器的理解会完全不一样。搞明白两者的差异，以后进公司接手的任何 PHP 老项目你都不会慌。

1.2 选 ThinkPHP 和 Laravel 的真实理由

ThinkPHP 的优势是"快"。特别是它的 5.x/6.x 系列，目录结构直观，上手门槛低，本身又是国内社区维护，中文文档全，报错信息看一眼就能猜个八九不离十。做校园类管理系统，大多数需求都是表单提交加列表展示，用 ThinkPHP 的模型层写起来非常顺手。

Laravel 的优势是"规范"和"生态"。中间件、服务提供者、门面、Eloquent ORM，这套设计模式学一次受用很久。如果以后想走 PHP 后端这条路，Laravel 是简历上很关键的技能点。做这个项目时，我用 Laravel 重写同一套接口，最大的印象是它的验证器（Form Request）和中间件机制，能让接口代码瘦一大圈。

需要说明一点：这不是说哪个框架"更好"——我自己的结论是，在校园微型活动报名这个场景下两者都绰绰有余，差距更多体现在开发习惯上。ThinkPHP 适合追求速度的个人开发者，Laravel 适合需要长期维护、多人协作的团队项目。论文里做对比时，这个结论比"谁吊打谁"要站得住脚。

从架构上看，整套系统拆成三块：

• 微信小程序端：活动浏览、搜索、报名、扫码签到（可扩展）、个人中心。
• 管理端 Web 页面：活动发布、报名审核、人员导出、数据统计。
• 后端 API 服务：分别基于 ThinkPHP 和 Laravel 实现，对外提供统一风格 JSON 接口。

小程序和后台之间只有 HTTP 接口通信，互相不干扰。小程序审核失败或者 UI 改版时，后端完全不用动。

2. 从需求到功能清单：微活动报名系统到底要拆成几块

2.1 用户端小程序功能边界

学生打开小程序后，第一屏是活动列表。这里有个容易被忽视的细节：校园活动的时效性很强，"报名中""已结束""待审核"这些状态必须在列表里明确展示。我建议后端返回数据时直接把status字段算好，小程序端只做展示，不要把"当前时间是否在报名区间"这个判断逻辑写在小程序里——原因很简单，小程序发布要审核，活动时间调整是高频操作，如果状态靠前端判断，活动一改时间你就得发版本。

活动的详情页，核心信息是：封面图、时间、地点、主办方、名额、报名截止时间、活动介绍。这里需要考虑两种活动类型：

• 无需审核的活动：报名后立即成功，立刻占用名额。
• 需审核的活动：比如一些人数受限的讲座、面试类的比赛，报名后进入"待审核"，管理员通过了才算报名成功。

用户报名时要填的字段也不能一刀切。比如普通讲座，填个姓名、学号、联系方式就够了；但如果是面试类活动，你可能还要收集"个人简介""意向岗位"。所以数据库设计里我预留了一个form_config字段，管理员建活动时用 JSON 配置报名表单，后端动态解析，这样灵活性高很多，避免每种活动做一个接口的窘境。

个人中心要展示"我的报名"，并支持取消报名。不过要注意，审核通过的活动是不是允许取消，这是个业务决策。我在项目里做了配置开关：活动可取消、报名截止前可取消。这样志愿者活动这类需要锁定人头的场景，管理员不会因为有人临时放鸽子而暴走。

2.2 管理端后台功能边界

管理端我用的是简单的前端页面加 API 接口的方式，没有继续套前端框架。原因很实际：校园项目的管理员数量一般就几个人，并发极低，重点是把信息维护界面做清楚。需要的核心页面：

• 登录页（管理员账号密码登录）
• 活动列表页（分页、搜索、状态过滤）
• 活动编辑页（基本信息 + 报名表单配置）
• 报名记录页（按活动查看、筛选状态、导出 Excel）
• 数据概览页（活动数量、报名人数、参与率）

导出 Excel 是个容易被忽略但实际使用频率非常高的功能。活动结束后，主办方要拿名单去现场核对，没有导出功能就只能一页页复制，体验很差。我用的方案是后端生成 CSV 文件返回下载链接，CSV 用 Excel 打开无压力，而且不依赖 PHPExcel 之类的重型库，性能也好。

管理端的权限不用做太复杂，因为服务对象是校内部门。我分了两个角色：超级管理员能管理所有活动和成员，普通管理员只能管理自己创建的活动。这个粒度对校园场景刚好，做复杂了反而是负担。

2.3 数据库表设计实战

这一块直接决定后面代码能不能写得顺。我踩过的坑是：一开始把报名信息全部塞在registration表里，活动字段、用户字段、自定义字段混在一起，后面前端一改需求，改表改到崩溃。

最终的表结构是下面这套，直接贴出来供参考。

users 表（小程序用户）

CREATE TABLE `users` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `openid` varchar(64) NOT NULL COMMENT '微信openid', `nickname` varchar(64) DEFAULT '' COMMENT '昵称', `avatar` varchar(255) DEFAULT '' COMMENT '头像', `student_no` varchar(20) DEFAULT '' COMMENT '学号', `real_name` varchar(32) DEFAULT '' COMMENT '姓名', `phone` varchar(20) DEFAULT '' COMMENT '手机号', `create_time` int(11) DEFAULT NULL, `update_time` int(11) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_openid` (`openid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='小程序用户表';

学号和手机号我设计成可选的，放在 users 表里。原因很直接：获取微信绑定手机号是付费接口，学生不一定愿意授权；让用户报名时手动填又很烦。所以项目里的做法是：报名时如果 users 表里没有手机号，则要求填一次，之后自动存入用户档案，下次报名就不需要再填了。这一版可以顺带解决活动报名里的"用户画像"问题。

activities 表（活动表）

CREATE TABLE `activities` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `title` varchar(128) NOT NULL COMMENT '活动标题', `cover` varchar(255) DEFAULT '' COMMENT '封面图URL', `location` varchar(128) DEFAULT '' COMMENT '活动地点', `organizer` varchar(128) DEFAULT '' COMMENT '主办方', `start_time` int(11) NOT NULL COMMENT '活动开始时间', `end_time` int(11) DEFAULT NULL COMMENT '活动结束时间', `register_start_time` int(11) NOT NULL COMMENT '报名开始时间', `register_end_time` int(11) NOT NULL COMMENT '报名截止时间', `max_people` int(11) DEFAULT '0' COMMENT '名额，0为不限', `current_people` int(11) DEFAULT '0' COMMENT '已报名人数', `detail` text COMMENT '活动详情', `form_config` text COMMENT '报名表单配置JSON', `need_audit` tinyint(1) DEFAULT '0' COMMENT '是否需要审核', `can_cancel` tinyint(1) DEFAULT '1' COMMENT '是否可取消报名', `status` tinyint(1) DEFAULT '1' COMMENT '状态 1正常 0下架', `create_time` int(11) DEFAULT NULL, `update_time` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_start_time` (`start_time`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='活动表';

注意时间字段我用的是整型时间戳而不是datetime。这个选择很有争议，但我的理由很实在：小程序端拿到时间戳可以直接传给new Date()，不用处理 "2025-06-01T10:00:00" 这种格式在不同 iOS 版本下的解析差异；后端比较时间也不用纠结"字符串时间"和"时间戳"谁大谁小。唯一要注意的是，给前端返回 JSON 时，把时间戳同时格式化一个"YYYY-MM-DD HH:mm"的字符串一起返回，前端展示直接用，省得各端重复写格式化函数。

registrations 表（报名记录）

CREATE TABLE `registrations` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `activity_id` int(11) NOT NULL COMMENT '活动ID', `user_id` int(11) NOT NULL COMMENT '用户ID', `fields_data` text COMMENT '报名表单提交的自定义字段JSON', `status` tinyint(1) DEFAULT '0' COMMENT '0待审核 1通过 2拒绝', `remark` varchar(255) DEFAULT '' COMMENT '审核备注', `cancel_time` int(11) DEFAULT NULL COMMENT '取消时间', `create_time` int(11) DEFAULT NULL, `update_time` int(11) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_activity_user` (`activity_id`, `user_id`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='报名记录表';

这里加了联合唯一索引uk_activity_user，目的就是挡住程序层面的并发重复报名。比如学生连续点两次报名按钮，如果没这个索引，极端情况下可能插入两条记录。数据库的唯一约束是最后一道防线，比你在代码里各种 if 判断都可靠。

admins 表（管理员表）相对简单：id、username、password_hash、role、last_login_time。密码存储用password_hash()函数，不要用 md5，这个没有讨论余地。

表设计里还需要注意两点：

一是所有业务表都加了create_time和update_time。ThinkPHP 的自动时间戳和 Laravel 的 Eloquent 都能直接接管这两个字段，代码里不需要手动赋值。二是"已报名人数"current_people这个字段，很多新手会忽略，导致每次查询都要COUNT(*)。这个字段是报名成功的实时快照，也是后面并发控制的锚点，必须在事务里更新，不能靠查询统计。

3. 小程序端核心实现：登录、报名、列表加载

3.1 登录链路：wx.login 换取 openid + 自定义 token

微信小程序登录是这套系统的地基。完整流程这样走：

1. 小程序端调用wx.login()，拿到临时凭证code。
2. 小程序把code通过wx.request()发到后端接口/api/login。
3. 后端用code请求微信的code2Session接口，换回openid和session_key。
4. 后端在users表里查这个openid，不存在则创建新用户，存在则更新登录时间。
5. 后端生成一个登录令牌（我用的token = md5(openid + secret + 时间戳)），存到缓存（Redis 或数据库表），再返回给小程序。
6. 小程序把token存到wx.setStorageSync，后续所有请求的请求头带上Authorization: Bearer <token>。

请求头带 token 的方式，和后端框架中间件配合最舒服。ThinkPHP 和 Laravel 里都可以写一个"用户认证中间件/行为拦截器"，校验 token 不过就直接返回401，业务代码不用每个方法都写一遍"是否登录"的判断。

有一处细节：新版微信把wx.getUserInfo改成了头像昵称填写能力，所以不要再依赖wx.getUserInfo弹窗去拿昵称头像了。项目里的做法是，首次登录时引导用户进入一个"完善个人资料"页面，用<button open-type="chooseAvatar">和<input type="nickname">收集头像和昵称，后端存进users表。这样既合规，又能保证后续活动报名时有基本的用户信息。

3.2 报名表单怎么设计才不会被骂

报名是系统的核心动作，交互上有一个原则：报名按钮点击之后，要么明确告诉你"报上了"，要么明确告诉你"为什么没报上"，绝不能卡在中间状态。

我的设计分三步：

第一步，判断登录态和业务状态。请求报名接口前，小程序先检查本地有没有 token；然后后端返回活动详情时已经带了apply_status（我定义：none未报名、pending待审核、approved已通过、rejected已拒绝），前端根据这个状态决定按钮文案和可用性。

第二步，动态表单渲染。活动详情接口返回的form_config是一个 JSON 数组，结构类似：

[ { "field": "real_name", "label": "姓名", "type": "input", "required": true }, { "field": "student_no", "label": "学号", "type": "input", "required": true }, { "field": "gender", "label": "性别", "type": "radio", "options": ["男", "女"], "required": true }, { "field": "department", "label": "学院/专业", "type": "input", "required": false } ]

小程序端遍历这个数组，动态渲染出对应的输入框、单选框、多选框。不要针对每种活动写死表单，否则每加一个新活动类型就要发一次小程序版本。后端在接收到报名数据时，也要按form_config的配置去校验字段是否齐全、是否在可枚举的选项里——这一步千万不能省，因为小程序端校验可以被绕过，直接 POST 非法数据完全拦不住。

第三步，提交报名。提交成功后的反馈也要分级：不用审核的活动，直接提示"报名成功"并更新按钮状态；需要审核的提示"已提交，等待审核"。这里注意，前端不能因为提交成功就把current_people加 1，因为审核拒绝后这个名额会被释放，你在前端做的加法是无效的。正确做法是只更新apply_status，让用户看到状态变化。

3.3 列表分页与"加载更多"

活动列表用onReachBottom触底加载下一页。这功能看起来简单，但新手经常在三个地方翻车：

第一，分页参数命名要对齐。我约定后端接口统一用page和page_size，返回结构固定为：

{ "code": 0, "message": "ok", "data": { "list": [], "total": 46, "page": 1, "page_size": 10, "has_more": true } }

前端判断has_more是否为true决定要不要显示"加载中..."提示。不要靠list.length < total这种间接判断，直接暴露has_more字段，语义最清晰。

第二，防止重复请求。用户手指快速滑动到底，onReachBottom可能在一秒内触发两三次。代码里要加一个锁：请求期间loading = true，加载完成loading = false；如果loading === true直接return。这是列表分页最常见的 bug，没有锁的话数据会重复。

第三，下拉刷新要处理好。onPullDownRefresh触发后，清空列表、页码重置为 1、重新请求，数据回来之后调用wx.stopPullDownRefresh()。注意请求要用setData替换整个列表而不是push，否则下拉刷新后旧数据还在，体验极差。

顶部导航栏高度这个话题，热词里也出现了。小程序胶囊按钮的位置在不同机型上不一样，如果要自定义导航栏，建议用wx.getWindowInfo()（老版本是wx.getSystemInfoSync()）拿状态栏高度，然后适配导航栏高度。我自己的做法是，能不用自定义导航栏就不用自定义，默认导航栏足够顺手；只有首页这种需要把背景融进导航栏的设计，才用"navigationStyle": "custom"，并且用官方文档的模板去适配，别自己写死在某个机型尺寸上。

4. 后端接口设计与并发控制

4.1 接口风格与统一返回结构

不管用 ThinkPHP 还是 Laravel，对外接口风格必须统一。我的做法很简单，封装两层：

一层是全局响应结构。所有接口返回code、message、data三段式：

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

业务错误用code区分，而不是用 HTTP 状态码。比如"报名已满"返回code: 1001，"活动已截止"返回code: 1002。原因很实际：小程序端wx.request在 HTTP 状态码非 2xx 时会走fail分支，而业务错误本质上是"请求到达且处理了，只是业务逻辑不通过"，走success分支更容易统一处理。当然，接口收到错误格式、未授权这类系统级错误，还是要返回对应的 HTTP 状态码。

另一层是参数校验。Laravel 可以用 FormRequest，ThinkPHP 可以用 Validate 类。不要图省事在控制器里用$_POST['xx']之类的方式拿参数，必须统一走验证器。举个最简单的例子，分页参数page是数值类型，page_size有上限，这些校验不写，恶意请求传个字符串可能导致 SQL 拼接报错甚至注入。

4.2 报名的并发控制：防重复、防超卖

这是整个系统技术含量最高的部分，也是论文里能出彩的地方。场景是：一个有 200 个名额的讲座，开放报名瞬间可能涌入 800 个请求。如果代码逻辑是"先查询当前人数，再判断是否小于名额，然后插入报名记录，最后人数加一"，高并发下一定会出现超卖——前面查询都返回 199，后面全部插入成功，人数变成 205。

解决思路有两层，建议两层都做：

第一层，用唯一索引挡住重复。这个前面提过，registrations表有(activity_id, user_id)唯一索引，同一用户无论如何都不会插入两条。报错捕获后转为友好提示"你已报名过该活动"。

第二层，用事务加原子更新来锁名额。不再做"查询再判断"，而是直接更新：

// ThinkPHP 6 事务写法 Db::startTrans(); try { // 原子扣减名额，affected rows 为 1 才说明扣减成功 $updated = Db::name('activities') ->where('id', $activityId) ->where('current_people', '<', Db::raw('max_people')) ->where('register_end_time', '>', time()) ->inc('current_people') ->update(); if (!$updated) { Db::rollback(); return error('名额已满或不在报名时间内'); } // 插入报名记录 Db::name('registrations')->insert($data); Db::commit(); } catch (\Exception $e) { Db::rollback(); return error('报名失败，请稍后重试'); }

这条UPDATE ... WHERE current_people < max_people是关键，数据库行锁保证了同一时间只有一个事务能把这个条件判断从true改成false。就算 1000 个请求同时进来，数据库会排队执行这个更新，前 200 个成功，第 201 个的WHERE条件不成立，更新到的行数为 0，事务回滚，名额不会超。

Laravel 的写法思路完全一样，只是语法换成 Eloquent 或 DB Facade：

DB::transaction(function () use ($activityId, $data) { $updated = DB::table('activities') ->where('id', $activityId) ->where('current_people', '<', DB::raw('max_people')) ->where('register_end_time', '>', time()) ->increment('current_people'); if (!$updated) { throw new \Exception('名额已满或不在报名时间内'); } DB::table('registrations')->insert($data); });

这里inc和increment都是生成原子更新语句，不要用"查出current_people，在 PHP 里加 1，再写回"的做法，那在多请求下必然丢更新。

还有一种方案是 Redis 的DECR原子操作预扣名额，但考虑到校园项目并发量级和部署复杂度，数据库事务已经足够。如果你的论文想做更高层次的优化，可以在论文的"进一步展望"里提 Redis + 消息队列削峰，但项目落地用事务版本更稳。

4.3 ThinkPHP 与 Laravel 代码迁移的注意点

同一套业务逻辑写两遍，这个工作量比想象中大，但很有价值。我迁移时的经验教训主要有这几点：

• 模型层的差异：ThinkPHP 的模型是「数据表→模型类」的直接映射，查询构造器链式调用很顺手；Laravel 的 Eloquent 模型更强调关联关系定义，with()预加载用起来很优雅。迁移时不要试图在网络层用同一套 API——那是徒劳，要按框架自己的习惯重写。

• 中间件 vs 行为拦截器：Laravel 的中间件是标准化的，auth中间件绑定到路由上，非常清晰；ThinkPHP 6 的中间件机制也接近 Laravel，但老项目里常看到用"初始化方法"_initialize()或行为扩展来做登录校验，代码结构会散。新项目尽量用中间件，别用老土办法。

• Config 和 Env 管理：Laravel 的.env机制非常规范，ThinkPHP 6 也有.env支持，两者都通过环境变量区分本地/测试/生产配置。不要把数据库密码写死在代码里，迁移时要记得检查。

• 验证器：Laravel 是有独立 FormRequest 的，校验逻辑和控制器完全解耦；ThinkPHP 的验证器也类似，但要手动引入。如果项目里有大量表单，两套框架都建议把所有validate规则抽出来单独管理，不要散在控制器里。

关于框架版本，我建议使用 ThinkPHP 6.0 和 Laravel 10.x/11.x，这两个都是各自的主流稳定版本，文档完善，PHP 版本要求也一致（PHP 8.x），不会因为版本太老引入一堆兼容性问题。

5. 部署上线与常见问题排查

5.1 本地联调：小程序开发者工具的 API 配置

这是每个新手都会卡一下的地方。小程序端wx.request的url必须是 HTTPS 域名，而且要在小程序后台配置合法域名。本地开发时怎么办？开发者工具里勾选"不校验合法域名..."，同时把url写成http://127.0.0.1:8000或者局域网 IP（比如http://192.168.1.101:8000），真机预览时手机和电脑连同一个 Wi-Fi 才能访问到。

一个很实用的细节：接口地址不要写死在代码里。我在小程序端维护一个config.js文件，里面写上：

const BASE_URL = 'http://127.0.0.1:8000'; // 本地环境 // const BASE_URL = 'https://api.example.com'; // 生产环境

每次切换环境改这一个文件就行。有人会更进阶地做成"编译时注入"，但我觉得校园项目没这个必要，别过度设计。需要强调的是，真机预览时如果能联网但请求报"url not in domain list"，那是域名白名单问题，不是代码 bug。

5.2 服务器部署要点

部署方案建议用一台最低配的云服务器就够：2核4G 跑这个项目完全没问题，带宽 3M~5M 就行。服务器装好 PHP 8.x、Nginx、MySQL 8.0、Redis（如果用了），然后：

• Nginx 配置：PHP 项目统一入口是index.php，Nginx 需要配try_files $uri $uri/ /index.php?$query_string;，这样路由才能正常。ThinkPHP 默认自带伪静态规则，Laravel 官方文档也有 Nginx 配置示例，两者本质一样。
• 上传目录权限：活动封面图上传后要存在public/uploads这类目录，Nginx 运行用户必须有写权限。Windows 上开发没问题，一上 Linux 就报"目录不可写"，基本都是权限问题，chmod -R 755和chown www:www是常规操作。
• HTTPS：现在小程序强制要求域名是 HTTPS。最简单的方式是申请免费证书，不管是阿里云、腾讯云还是 Let's Encrypt，配好 Nginx 443 端口就行。证书续期要写到计划任务里，不然三个月后就过期，小程序白屏，用户还以为是你们的系统崩了。

配置好之后还有个常用操作：数据库导入和迁移。论文项目不是复杂的线上迭代，直接导出 SQL 导入即可，不用上迁移工具。但要保证导入后数据表的字符集是utf8mb4，不然存个 emoji 或生僻字就变成乱码。

5.3 高频报错与解决方案

把我在实际跑这个项目时遇到的问题按出现频率整理成速查表：

这一版项目我按"用户端活动列表 → 活动详情 → 报名流程 → 后台活动管理 → 报名管理 → 数据导出"闭环跑通后才写的文档。当初在"报名并发超卖"这个问题上我翻了两次车：第一次用查询再判断，压测到 500 并发时就超了 3 个名额；第二次加上唯一索引和事务原子更新后再压测，2000 并发也不超卖。这个对比数据在论文里非常有用——用数据说话永远比空洞的"高并发设计"有说服力，你可以把压测工具（如 JMeter 或 ab）的测试结果截图放进去。

最后分享两个小经验。

一是不要把论文里的对比部分写成"我用了两个框架，功能都一样"。要把差异落到实处：比如同样一个报名接口，ThinkPHP 我写了 80 行，Laravel 因为用 FormRequest 和资源类只需要 55 行；再用工具测一下两个接口在 500 并发时的平均响应时间，这个数据比嘴上的分析有价值得多。

二是系统里始终保留一个"导出报名名单 Excel"的功能。这个功能可能不起眼，却是管理员使用频率最高的功能。学校里的实际用户不会关心你用了什么框架、Redis 怎么部署的，他们只关心"报名名单导出来方便吗"。这个功能做顺手了，系统的口碑才能真正立起来。

做这类校园项目，技术只是一部分，花时间把报名、审核、导出这条链路打磨顺，让主办方和学生都觉得"比问卷星好用"，这个系统就值得写进论文了。