企业官网建设流程全解析

1. 从一张Excel表说起：为什么我要自己动手写教师信息管理系统

三年前，我接手了一个培训机构的教务协调工作。当时他们管理三十多位兼职教师的方式，说出来你可能不信——一个名为“教师通讯录最终版2023不要改.xlsx”的文件，外加三个微信群。排课靠翻聊天记录，查教师资质靠回忆，月底统计课时得把五六个表格来回粘贴。最离谱的一次，一位老师同时被排了两节课，而另一位老师整整一周没收到任何通知，原因就是表格里她的名字被误删了。

这件事之后，我下定决心要搞一套真正能用的教师信息管理系统。市面上的成品要么太贵，要么功能冗余到让人抓狂，要么数据存在别人服务器上让我不放心。于是，我花了大概两个月业余时间，从零搭了一套自用的系统。它不复杂，但足够解决我遇到的所有痛点：教师档案集中管理、课程安排可视化、课时自动统计、资质到期提醒。

这篇文章就是把这套系统的设计思路、技术选型、踩过的坑和最终跑通的方案完整分享出来。如果你也在被Excel和微信群折磨，或者你是个刚入门想找个练手项目的开发者，再或者你是机构管理者想了解一套轻量级系统该怎么落地，这篇内容应该能帮到你。我会尽量说人话，把每个选择背后的“为什么”讲清楚，让你看完就能照着搭一套属于自己的版本。

2. 需求拆解：教师管理到底要管什么

2.1 核心痛点与功能边界

很多人一上来就想搞个大而全的系统，结果做到一半就烂尾了。我的经验是，先把“必须要有”和“以后再说”分清楚。教师信息管理系统的核心其实就四件事：存得住、查得快、算得准、提醒得到。

存得住，指的是教师的基本信息、资质证书、合同文件、授课记录这些数据要有一个统一的存放位置，不能散落在各个微信对话框和邮箱附件里。查得快，是指当你要找“能教高中物理、有三年以上经验、周末有空”的老师时，能在几秒内筛出来，而不是一个个翻档案。算得准，是课时统计、薪酬计算不能出错，这是最容易引发纠纷的地方。提醒得到，是合同到期、资质年审、续签节点这些时间敏感的事项要能自动预警。

我最终确定的功能模块包括：教师档案管理（含附件上传）、课程与排课管理、课时统计与报表、到期提醒、多角色权限（管理员和普通查看者）。至于考勤打卡、在线直播、家长端这些，我全部砍掉了，因为那属于另一个系统的范畴。

2.2 用户角色与权限设计

这套系统主要面向两类人：管理员和查看者。管理员可以增删改查所有数据，查看者只能看不能改。听起来很简单对吧？但这里有个坑：很多自研系统一开始只做一个超级管理员账号，所有人共用，结果出了数据问题根本查不到是谁改的。

我的做法是，即使是小团队，也要给每个人分配独立账号，并且记录关键操作的日志。比如谁在什么时候修改了某位教师的课时费标准，谁删除了某条排课记录。这个日志不需要多复杂，一张操作记录表就够了，字段包括操作人、操作时间、操作类型、操作对象、变更前后的值。后来证明这个决定太正确了，有一次课时统计对不上，我花了十分钟就定位到是某位同事误操作导致的。

权限控制我用的是最简单的基于角色的访问控制模型，没有引入复杂的权限框架。具体来说，用户表里加一个role字段，值就是admin或viewer，然后在每个接口入口做一次判断。对于自研自用系统，这完全够用，没必要上那些重量级的权限管理库。

2.3 数据实体关系梳理

在动手写代码之前，我强烈建议你先在纸上把实体关系画清楚。我当初就是急着写代码，结果做到一半发现表结构设计有缺陷，不得不推倒重来。教师管理系统的核心实体包括：教师、课程、排课记录、课时统计、附件、用户、操作日志。

教师和课程是多对多关系，一个老师可以教多门课，一门课也可以由多个老师教。排课记录是教师和课程的交集，同时关联具体的时间段。课时统计是从排课记录聚合出来的，按教师、按月份汇总。附件表用来存教师资格证、学历证书、合同扫描件这些文件，通过外键关联到教师。

这里有个细节值得注意：教师的状态字段。我一开始只设计了“在职”和“离职”两种状态，后来发现不够用。比如有的老师是“休假中”，有的“已签约但未开课”，有的“试用期”。这些状态在排课和统计时的处理逻辑是不一样的。所以后来我改成了枚举类型，包含：待入职、试用期、在职、休假、已离职。这个改动虽然小，但让后续的筛选和统计准确了很多。

3. 技术选型：为什么我选了这套看起来“不够时髦”的方案

3.1 后端框架的取舍

选后端框架的时候，我考虑过几个选项：Spring Boot、Django、Express、Flask。最后我选了Flask。原因很简单：这套系统的并发量极低，用户数最多几十个，每天请求量撑死几千次。Spring Boot对我来说太重了，启动慢、配置繁琐，虽然生态强大但我用不上那么多功能。Django倒是不错，自带Admin后台，但它的ORM和模板系统我用不太习惯，而且我想前后端分离，Django的强耦合设计反而碍事。

Flask的好处是轻、灵活、上手快。我需要什么就装什么，不需要的绝不引入。整个后端代码量大概两千行左右，结构清晰，维护起来毫无压力。数据库我选了PostgreSQL，而不是MySQL。原因是我需要用到一些JSON字段来存半结构化的数据，比如教师的可授课时间段，PostgreSQL对JSON的支持更成熟。另外它的全文检索功能也帮了大忙，后面会细说。

提示：如果你是个新手，想照着做一套，用SQLite也完全可以。数据量小的时候，SQLite的性能绰绰有余，而且零配置，备份就是复制一个文件。等数据量大了再迁移到PostgreSQL，迁移成本也不高。

3.2 前端方案：为什么放弃React选了Vue

前端我纠结了很久。React生态更大，但学习曲线陡；Vue上手快，文档对中文用户友好。考虑到这套系统主要是自己用，偶尔给同事用，不需要太复杂的交互，我最终选了Vue 3加上Element Plus组件库。Element Plus的表格、表单、日期选择器这些组件开箱即用，省了我大量写CSS的时间。

整个前端没有用TypeScript，用的是JavaScript。我知道现在TS是主流，但对于一个自用项目，JS的开发速度更快，不用花时间定义各种类型。当然，如果你的项目会长期迭代、多人协作，那还是上TS更稳妥。我这里的选择是基于“一个人、两个月、快速跑通”这个前提做的。

构建工具用的是Vite，比Webpack快太多了。热更新几乎秒级，开发体验很好。打包出来的文件也不大，部署到服务器上很轻松。

3.3 部署与运维的极简主义

部署这块我走的是极简路线。一台最低配的云服务器，装个Nginx做反向代理，后端用Gunicorn跑Flask应用，前端打包成静态文件直接由Nginx托管。数据库和应用跑在同一台机器上，因为数据量小，没必要分开。备份策略是每天凌晨用pg_dump导出数据库，保留最近30天，同时把附件目录同步到对象存储。

我没有用Docker。不是说Docker不好，而是对于这种单机部署的小项目，Docker带来的额外复杂度大于收益。直接装Python环境、配好依赖、写个systemd服务文件让它开机自启，就完事了。当然，如果你对Docker很熟，用Docker也没问题，只是记得把数据卷挂载好，别把数据弄丢了。

监控方面，我装了一个简单的健康检查接口，然后用一个免费的监控服务定时ping一下，挂了就发邮件通知我。日志直接用Python的logging模块写到文件，配合logrotate做切割。没有上ELK那套，因为没必要。

4. 核心功能实现：从教师档案到课时统计的完整链路

4.1 教师档案模块：不只是存个名字和电话

教师档案是整套系统的基石。我设计的教师表包含以下字段：姓名、性别、手机号、邮箱、身份证号（加密存储）、最高学历、毕业院校、专业、职称、可授课程、可授课时间段、入职日期、状态、备注。其中“可授课程”和“可授课时间段”用的是JSON数组，方便灵活扩展。

这里重点说一下可授课时间段的存储设计。一开始我想用字符串存，比如“周一至周五 9:00-18:00”，但后来发现这样没法做筛选。比如我想找“周三下午有空”的老师，字符串匹配根本做不到。后来改成了结构化的JSON，格式如下：

{ "monday": [{"start": "09:00", "end": "12:00"}, {"start": "14:00", "end": "18:00"}], "wednesday": [{"start": "14:00", "end": "17:00"}], "saturday": [{"start": "09:00", "end": "12:00"}] }

这样在排课时，我就可以精确判断某位老师在某个时间段是否可用。查询的时候用PostgreSQL的JSONB操作符，效率也不错。

附件上传功能我用的是本地文件系统存储，数据库里只存文件路径和元信息。文件按教师ID分目录存放，避免单个目录文件过多。上传时做了类型和白名单校验，只允许PDF、JPG、PNG三种格式，大小限制在10MB以内。这些校验在前端和后端都要做，前端提升用户体验，后端保证安全。

注意：身份证号这类敏感信息一定要加密存储。我用的是对称加密，密钥放在环境变量里，不写在代码中。虽然自用系统安全要求没那么高，但养成好习惯总没错。

4.2 排课与冲突检测：一个看似简单实则容易翻车的地方

排课功能是整套系统里逻辑最复杂的部分。表面上看，就是把老师、课程、时间、教室四个要素组合起来，但实际做的时候，冲突检测能把你逼疯。我定义的冲突规则包括：同一教师同一时间段不能排两节课、同一教室同一时间段不能排两节课、同一教师同一天排课总时长不能超过设定上限。

实现冲突检测的核心逻辑是：在插入或更新排课记录之前，先查询数据库中是否存在时间重叠的记录。时间重叠的判断条件是：新排课的结束时间大于已有排课的起始时间，且新排课的起始时间小于已有排课的结束时间。这个条件看起来简单，但写SQL的时候很容易写错，尤其是涉及到跨天排课的时候。

我踩过的坑是：一开始只检查了教师冲突，忘了检查教室冲突。结果有一次两位老师被排到了同一个教室，幸好发现得早。后来我把冲突检测抽象成了一个独立的函数，传入教师ID、教室ID、时间段，返回冲突列表。这样无论是新增还是修改，都调用同一个函数，保证逻辑一致。

排课界面我用的是日历视图，按周展示。每个时间段是一个可点击的格子，点击后弹出对话框选择课程和教师。已经被占用的格子会显示课程名称和教师姓名，并且不可点击。这个交互方式比表格直观很多，同事们上手就会用。

4.3 课时统计：从原始记录到薪酬报表的自动化

课时统计是我最看重的功能，因为它直接关系到钱。我的设计思路是：排课记录是原始数据，课时统计是从原始数据聚合出来的结果。每次排课记录发生变更，系统会自动重新计算受影响的统计周期。

统计维度包括：按教师汇总、按月份汇总、按课程汇总。每个维度下又分“计划课时”和“实际课时”。计划课时来自排课记录，实际课时来自课后确认。这里我加了一个“确认”机制：每节课结束后，管理员需要手动确认这节课是否正常进行。如果正常，实际课时等于计划课时；如果取消或调整，实际课时相应变化。这个机制避免了“排了课但没上”却照样算钱的情况。

薪酬计算我用的是规则引擎的思路。每位教师可以设置不同的课时费标准，比如普通课100元/小时，精品课150元/小时，晚班加20%。这些规则存在教师表的JSON字段里，计算时动态解析。这样不用改代码就能调整薪酬规则，灵活性很高。

报表导出用的是Python的openpyxl库，生成Excel文件。格式我做了精心设计：表头冻结、列宽自适应、数字右对齐、金额加千分位。这些细节虽然小，但让报表看起来专业很多，发给财务的时候省了不少解释的功夫。

5. 那些让我熬夜的坑：问题排查与解决实录

5.1 中文全文检索的曲折经历

教师档案多了之后，搜索成了问题。用LIKE '%关键词%'的方式查询，数据量一大就慢得离谱，而且不支持分词。比如我搜“物理”，它没法匹配到“高中物理”和“大学物理”中的“物理”这个词。后来我决定上全文检索。

PostgreSQL自带的全文检索对中文支持不好，因为它默认的分词器是按空格和标点分的，中文句子没有空格，分出来全是整句。我试过用zhparser扩展，但安装配置折腾了好久，而且在云服务器上编译安装总是报错。后来我换了一个思路：用jieba分词在应用层做处理，把教师的可授课程、备注等字段预先分词，存到一个专门的搜索字段里，然后用PostgreSQL的tsvector做索引。

具体做法是：在教师表加一个search_vector字段，类型是tsvector。每次新增或更新教师信息时，用Python的jieba对相关字段分词，然后用to_tsvector函数生成向量。查询时用plainto_tsquery或to_tsquery构造查询条件。这样搜索“物理”就能匹配到所有包含“物理”这个词的教师，而且速度很快。

这个方案的好处是不依赖数据库扩展，纯应用层解决，迁移方便。缺点是分词在应用层做，稍微增加了写入时的开销，但对于教师管理这种写入频率极低的场景，完全可以接受。

5.2 时区问题导致排课时间错乱

这个问题困扰了我整整一个周末。现象是：我在前端选择“下午2点”，存到数据库变成“下午6点”，再读出来又变成“晚上10点”。一开始我以为是前端日期选择器的bug，查了半天没找到原因。后来才意识到是时区问题。

我的服务器默认时区是UTC，而我在前端传的是本地时间。Flask默认把时间当UTC处理，存到PostgreSQL里也是UTC。但PostgreSQL的timestamp类型不带时区信息，读出来的时候又按本地时区解释，一来一回就差了8小时。

解决方案是：统一使用带时区的timestamp类型，并且在应用层明确指定时区。具体来说，数据库字段用timestamptz，Python代码中所有datetime对象都带上tzinfo，前端传时间时用ISO 8601格式并包含时区偏移量。这样无论服务器在哪个时区，显示出来的时间都是正确的。

提示：时区问题是Web开发中最容易踩的坑之一。我的建议是，从项目第一天起就统一用UTC存储，只在展示给用户的时候转成本地时间。千万别混用，否则后患无穷。

5.3 并发写入导致的数据不一致

虽然这套系统用户不多，但偶尔还是会出现两个人同时操作同一条记录的情况。有一次，管理员A在修改某位教师的课时费标准，管理员B同时在给这位教师排课。结果A的修改被B的排课操作覆盖了，课时费标准又变回了旧值。

这个问题本质上是并发写入冲突。解决方案有两种：乐观锁和悲观锁。我选了乐观锁，因为冲突概率低，悲观锁会降低并发性能。具体实现是：在教师表加一个version字段，每次更新时version加1。更新语句带上version条件，如果version不匹配，说明数据已被他人修改，更新失败，提示用户刷新后重试。

UPDATE teachers SET name = '张三', version = version + 1 WHERE id = 123 AND version = 5;

如果受影响行数为0，说明version不匹配，前端弹出提示“数据已被他人修改，请刷新后重试”。这个机制简单有效，后来再没出现过覆盖问题。

5.4 附件上传的大小限制与超时

附件上传功能上线后，有同事反映上传大文件时经常失败。我排查后发现两个问题：一是Nginx默认的client_max_body_size是1MB，超过就报413错误；二是Gunicorn的默认超时是30秒，大文件上传容易超时。

解决方法是：在Nginx配置里把client_max_body_size调到20MB，在Gunicorn配置里把timeout调到120秒。同时在前端做了文件大小预校验，超过10MB直接提示用户压缩后再传。另外，上传进度条也很重要，让用户知道系统在干活，而不是卡死了。

这些配置看起来简单，但如果不熟悉的话，能查半天。我把它们记在这里，希望你不用再踩一遍。

6. 让系统更好用：几个提升体验的细节设计

6.1 到期提醒：不让任何一份合同被遗忘

到期提醒功能是我最满意的设计之一。系统每天凌晨跑一个定时任务，检查所有教师的合同到期日、资质证书有效期、续签提醒日。如果距离到期日不足30天，就生成一条提醒记录，并在管理员登录时弹出提示。

提醒的粒度我做了分级：30天前提醒一次，7天前再提醒一次，到期当天最后提醒。提醒方式包括站内消息和邮件。邮件用的是SMTP协议，配置一个发件邮箱即可。为了避免邮件轰炸，同一个事项在同一天只发一次。

这个功能帮我避免了好几次合同过期未续签的尴尬。以前靠人脑记，总会漏；现在系统自动盯着，省心很多。

6.2 数据导入导出：从Excel平滑迁移

考虑到很多机构已经有现成的Excel表格，我做了数据导入功能。支持上传Excel文件，系统解析后批量导入教师信息。导入时做了字段映射和格式校验，比如手机号必须是11位数字，邮箱必须包含@符号。校验不通过的行会生成错误报告，让用户修正后重新上传。

导出功能同样重要。除了前面说的课时统计报表，我还做了教师档案导出、排课表导出。导出格式支持Excel和CSV，方便在不同场景下使用。

6.3 操作日志：出了问题能查到人

操作日志这个功能，平时用不上，但一旦出问题就是救命稻草。我记录的操作类型包括：新增教师、修改教师、删除教师、新增排课、修改排课、删除排课、确认课时、修改薪酬规则。每条日志包含操作人、操作时间、操作对象、变更前后的值。

日志查询界面支持按操作人、时间范围、操作类型筛选。有一次财务说某位教师的课时费算错了，我查了一下日志，发现是有人修改了这位教师的课时费标准但没有通知财务。日志里清清楚楚记录了修改前后的值，问题迎刃而解。

6.4 移动端适配：让排课不再局限于电脑前

虽然系统主要在电脑上使用，但有时候在外面需要用手机查一下某位老师的联系方式或者确认一下排课。所以我做了响应式设计，用CSS媒体查询让页面在手机屏幕上也能正常显示。表格在小屏幕上会变成卡片式布局，每个教师一张卡片，信息一目了然。

没有做独立的App，因为没必要。一个适配好的网页，加到手机主屏幕，用起来和App差不多。省去了开发和维护App的成本。

7. 这套系统教会我的几件事

做这套系统的过程中，我最大的收获不是技术上的，而是对“需求”的理解。一开始我想加很多功能，觉得这个也有用那个也有用，但真正做出来之后发现，常用的功能就那么几个。把核心功能做扎实，比堆砌一堆花哨功能重要得多。

另一个体会是，数据校验和错误处理要趁早做。我一开始图快，很多地方没做校验，结果后面数据乱了，花在清理数据上的时间比当初写校验的时间多十倍。现在我的原则是：任何用户输入都要校验，任何外部调用都要处理异常，任何数据变更都要记日志。

还有一点，不要过度设计。我见过太多自研项目死在“想做得太完美”上。先用最简单的方式跑通，然后再迭代优化。我的第一版系统连用户登录都没有，就是一个本地跑的单机应用。后来才慢慢加上权限、日志、提醒这些功能。如果一开始就追求大而全，可能到现在还没上线。

最后，如果你也想自己动手做一套管理系统，我的建议是：从你最痛的那个点开始，先做一个最小可用的版本，用起来，然后再改。不要等到“设计完美”了才动手，因为永远没有完美的那一天。