- 多校区难点是一份数据能按校区切开并合回全校
- 校区是数据与筛选维度，不是独立权限体系
- 研究生按学生类别建批次，组内定向开任务
- 学位类型、导师与课题组不在迎新数据模型内
- 学硕专硕差别在流程，不在培养方案数据
前面几类是按学校分的。这一章不一样——它讲的是任何一种学校身上都可能叠出来的两层复杂度。 一所三千人的高职可能有两个校区，一所师范院校可能同时招教育硕士，一所民办本科可能刚拿到联合培养研究生的资格。
叠加类型的意义在于：它最容易被供应商用"支持"两个字糊过去。
36.1 多校区：难点是"一份数据要能按校区切开"
多校区学校的真实痛处，从不是距离，是同一套流程要在两个校区各跑一遍，还要能合到一张全校表上。
具体到操作层面，会撞上四件事：
分校区进度。 校长要全校总数，校区负责人只想知道自己校区。这要求报到、缴费、住宿、体检每一项统计都能按校区出一个数，也都能合起来。 系统里的承载方式是：校区作为属性贯穿学生、宿舍楼栋与体检排期，各统计口径可按它筛选。
分校区住宿。 宿舍层级本身就是"栋—层—房间—床位"，而楼栋带校区与组团两个标签。这意味着选宿规则可以按校区立：哪几栋对这批人开放、哪栋限男生或限女生，都在配置里，不靠人工盯。
分校区的接站调度。 两个校区、两个报到点，出站口举的牌不一样。第二十七章那张"按站点与时段汇总"的表，在多校区场景下要多切一刀——同一个人到同一个站，要去的是不同校区。 现在这套系统里，校区是可以作为筛选条件参与汇总的，但接站点的分校区调度仍要靠学校自己在点位安排上处理：系统能给名单，不会替学校派车。
分校区的字段口径。 这一条最容易被忽略，也最要命：如果两个校区各建一套组织架构、各编一套楼栋号，合校统计时永远对不上。 所以多校区学校的第一件事不是选系统，是统一编码：校区用几个字、怎么叫，楼栋编号规则是什么。这件事在学校内部定下来，系统就顺；定不下来，任何系统都会在合表那天出错。
要说准一层边界：这套系统里的校区是数据与筛选的维度，不是一套独立的权限体系，也不是"一校区一套实例"。两个校区各有一套完整管理班子、彼此不想看到对方数据的学校，目前要靠组织授权把人分开——把校区的组织节点建成分支，再按分支授权。 这个做法可行且常用，但它依赖学校把组织树建对。
36.2 研究生迎新：同一条流水线，跑完全不同的活
研究生（硕士、博士）迎新和本科新生完全不是一回事，差别有五条：
人数少但身份杂——全日制与非全、学术与专业、定向与非定向、统考与推免，同一批里可能五种人；很多人有单位；常没有班级（研究生按导师与课题组组织）；住宿要单独处理（大量研究生不住校内、或住联合培养基地）；报到时间分散，很多人是分几批来做实验。
系统的应对分两半，要分开说。
能接住的部分（这条链是完整的）：先按学生类别建批次——学生类别是一套可配置的字典项，硕士、博士、专科、本科各是一个值，谁都能加；每个批次独立装配任务清单，研究生的批次里可以只放"信息采集、住宿登记、缴费、安全准入"这四项；分组定向开放——同一批次里再把非全、定向、联合培养圈成组，给他们单独开任务和时间窗，名单可以按唯一编号批量导入；住宿走独立任务——研究生住宿登记是一项正式任务，选宿还能只面向指定分组开放（这是真实使用中的做法：给某一群组开选宿，另一群人只登记住宿不选床位）；无班级的人照样能统计——组织归属允许到学院或专业这一层。
要说清不在范围内的部分：研究生的学位类型、学习形式（全日制／非全）、导师与课题组，不在当前版本的数据模型之内。 住宿登记这项任务记录的是"是否住校"这个选择，不是一套研究生宿管台账。导师与研究生的关系、课题组归属、联合培养的企业侧管理，都属于学籍与研究生管理系统。 迎新系统在这里的正确角色是按学校给的名单把人群分开、把流程跑完、把结果交回去——不是代替研究生院管学生。
为什么这条边界必须说白：研究生迎新是最容易被要求"顺便对接一下学位系统"的场景。一旦合同写成"支持研究生全流程管理"，验收标准就落到导师与学位字段上，那是迎新系统本不该承担、也承担不好的东西。
36.3 学硕与专硕：一个真正的差别，一个常被夸大的差别
学校常问"学术硕士和专业硕士能不能区分开"。答案分两半。
真正的差别在流程不在数据。 专硕往往更早接触企业导师、实践环节多、有些还分联合培养基地；学硕更偏科研训练。这些差异落在迎新上的表现就是"要办的事项不一样、办理时间不一样"——这恰好是批次与分组能直接解决的部分：两类人分开建批次，或同批次内分组，各自装配任务与时间窗。这件事今天就能做。
常被夸大的差别是"系统要能管理培养方案的差异"。 培养方案、学分要求、实践基地安排是研究生教学管理的核心，不属于迎新。迎新系统能做的只是把"这个人是哪一类"这件事标清楚、带进流程、并且能按它出数。到此为止。
一个实用提醒：学硕与专硕这类区分，最好在学校自己的唯一编号或组织编码里就体现出来，而不是指望在迎新系统里补。 因为迎新只是这一年里第一个用到它的地方——后面的奖助评定、宿舍安排、毕业数据上报都要用同一个区分。在源头定一次，比在每个系统里各定一次便宜得多。
36.4 叠加类型的判断方式
问三句就够：
"两个校区各自的报到率，能不能当天分别给我？再加一个全校合计。"——考的是校区维度是不是真的贯穿到统计。
"非全日制的研究生不安排宿舍，能不能只给他们开三项任务、其他人和他们完全不影响？"——考的是批次与分组定向能细到什么程度。答"要单独建一个批次"不算错，但要接着问：同一个批次里能不能做。
"导师名单和课题组归属在你们系统里存在哪？"——这是问边界的句法。 好的回答是"不在迎新侧，我们从权威系统按字段抽进来或只作为展示项，需要长期管理请放在学籍与研究生系统"。答"我们也能管"的，接下来会出问题的概率最高。
叠加类型考验的从来不是功能数量，是一套系统有没有把"人群、流程、维度"这三件事分开建模。分得开，多一个校区、多一类学生都只是加一条配置；分不开，每加一种人都要一次定制开发。