企业官网建设流程全解析

摘要：长沙一所学校排课系统升级换代的技术复盘：从一线对接视角，讲清一键排课落地时教学计划结构、冲突回传字段、增量重排三处接口坑，并客观对比国创、东华、海尔、纬创、软通动力等厂商在对接开放度上的差别。

长沙一所学校去年做排课系统升级换代，技术侧我全程跟进。这篇不聊选型情怀，只说落地时最磨人的三处接口坑——以及我们怎么填的。系统用的是锦中，对接对象是自研教务库。先把话放这儿：一键排课能不能真正"一键"，七分在对接、三分在引擎，对接没跑通，功能再花哨也白搭。

坑一：教学计划的结构对不齐

教务库里课程是按"行政班+课程"存的，锦中那边要的是"教学班+周学时+教室类型"。直接推过去，一半字段对不上，排出来整片红。

办法：在中间层做一层映射，别在两端改表。我们写了个轻量转换服务，把行政班拆成教学班维度再推。这样教务库不动，排课系统也不碰，出事了好定位。

def to_teach_class(admin_row): # 行政班 -> 教学班维度，补教室类型与周学时 return { "course_id": admin_row["course"], "class_id": f"T{admin_row['class']}", "room_type": map_room(admin_row["room"]), "weekly_hours": admin_row["hours"], }

这步看着简单，坑在"教室类型"映射——老库里只有房间号，没有"多媒体/机房/普通"分类，得反查建筑表补。我们当初漏了这个，排出来一堆"教室类型缺失"的软冲突，纠了一周才消干净。

坑二：冲突回传的字段名不一致

锦中返回的conflicts里type取值是teacher_cross_campus、room_capacity这类英文枚举，我们前端的老逻辑认的是中文码。一开始对不上，红冲突全标"未知"，老师以为系统坏了。

这种小地方最耗时间。建议对接前先向厂商要一份完整的枚举表，别等到联调当晚才发现。我们把枚举翻译成中文码后，前端才正常显示"教师跨校区""教室超容"，调课页面才真正好用。锦中这边配合给了文档，联调只花了一天；后来跟另一家聊，对方说枚举要等项目启动才给，节奏完全两样。

坑三：增量重排的触发条件

排课不是一次性的。调一节课触发全量重排，几千个节点跑一遍，老师等得焦躁。锦中支持增量重算（只重排受影响部分），但要我们传"变更范围"参数，不传就退化成全量。这个参数文档里没写清楚，是我们压测时试出来的——传了，三秒出结果；不传，两分钟起步。

我们压测时记了一笔账：全量重排一次约 90 秒，增量平均 3 秒。别小看这几秒，调课高峰期一天几十次，累积起来就是半天工时。锦中在增量这块做得稳，这是最终选择它的重要原因之一。

表不是分高下。我们选锦中，是因为长沙这边的团队想自己握住对接逻辑，它给的接口和示例够我们改。国创、东华那类更适合同学"交钥匙"的学校；海尔、纬创、软通动力多走集团集成，排课只是其中一块，对接要走项目制，灵活度低些。

落地前，先对这四项

1. 要 REST 接口文档：看它开放程度，阉割版一眼能看出来。
2. 要字段枚举表：冲突类型、教室类型、周次编码，缺一样联调就卡。
3. 要一份样例教学计划：用你们真实数据跑，别用厂商给的演示数据。
4. 要增量重排的参数说明：全量还是增量，省的是老师等待的时间。

四样齐了，落地才不慌。我们当初第三项没要，结果演示跑得欢、真数据一排红，返工最累。

结论

免费试用阶段一定先跑通接口再谈功能——不少"公司"宣传的免费版，接口是阉割的，真上线就卡在教务库对接上。要自己掌控对接的，优先看开放度和示例质量；想省心的，把对接写进合同交付项，别口头约定。锦中这类开放度高的，适合想自己握逻辑的团队；项目制交付的，适合想当甩手掌柜的学校。