公寓宿舍WiFi认证计费里，房源、房间和账号之间该怎么建模
公寓宿舍WiFi认证计费系统上线之后，运营方每天面对的问题并不只是"怎么收费"，更基础的问题是：账号到底跟谁绑定、跟哪间房绑定、房间状态变了以后网络策略跟着怎么变。很多公寓在系统里只建了一堆用户账号，没有把房源、房间、床位和账号之间的关系梳理清楚，结果换租时账号扯不清、合租时费用分摊乱、房间维修期间还在计费，月底对账全靠人工翻记录。认证计费平台本身提供了用户组、账号管理、绑定策略和状态控制能力，能不能用到位，前提是先把数据模型这一层设计明白。
先想清楚：账号挂在人身上，还是挂在房间身上
公寓宿舍场景有两种常见的建模思路。一种是以"人"为主体，每个住户一个独立账号，账号里记录手机号、实名信息、所属房间、所选套餐和余额，网络策略跟着账号走。另一种是以"房间"为主体，一间房一个房间账号，房间里谁入住谁用这个账号，多人合租时在房间账号下再分出子账号或者额度。两种思路没有绝对的好坏，区别在于公寓的运营方式不同。
长租公寓、员工宿舍这类人员相对固定、一户一账的场景，以人建模更直接：入住开户、退租销户、换租转移，每一步都对应具体账号，账单和实名记录都落在人头上。出租屋、短租床位、工厂倒班宿舍这类人员流动快、一间房多人轮换的场景，以房间或床位为主体建模会更顺手，账号跟随房源状态自动开通和停用，管理员不需要每换一个人就手工重建一遍关系。实际项目里也可以两层结合：上层是房源和房间，下层是住户账号，账号归属到房间，房间归属到楼栋和项目。认证计费平台支持划分多级用户组，楼栋、楼层、房间可以作为不同层级的分组，账号挂进对应分组后，策略、套餐和统计都按分组归集。
合租场景下，账号和费用怎么对应到床位
合租公寓最容易出问题的是费用归属。两室一厅住两个人，网络套餐是整房一份还是每人一份；四人床位宿舍，是每人单独购买套餐，还是房间统一购买后分摊。建模时需要先把这个规则定下来，再在系统里落到用户组和套餐上。
如果采用每人独立账号，各买各的套餐，系统按账号分别计费、分别出账单，退租只停对应账号，互不影响，这是最清晰的方式。如果采用整房套餐、多人共用一个额度，就要在房间账号下设置终端数量上限和同时在线人数限制，认证计费平台支持对同一账号允许同时在线人数、绑定终端数量做控制，后认证用户可以按规则把前一次在线会话踢下线。共用额度下谁用了多少流量、多少时长，平台的在线用户记录和上网流量记录可以作为分摊核对的依据，但分摊比例和收费口径要在租约和规则里提前写清楚，不能等住户来问时再临时解释。
账号与房间之间的绑定关系，应当在开户时记录完整：楼栋、楼层、房间号、床位号、入住人手机号、开户时间、所选套餐。这些字段既是认证策略下发的依据，也是后续换租、维修、退租和对账时检索的索引。平台支持把账号与MAC地址、NAS设备IP、VLAN、AC控制器IP、SSID等接入信息一并绑定，绑定关系和房源信息放在一起管理，排查问题时才能快速判断这个账号属于哪间房、从哪个网络区域接入。
房间状态机：空置、在租、维修、退租分别对应什么网络策略
房源在生命周期里会经历几种状态：空置待租、在租入住、维修清扫、退租待清扫、长期空置。每一种状态都应该对应一套明确的网络动作，而不是依赖管理员记得手动去停账号。
在租状态下，账号处于正常可用状态，按所选套餐的有效期和余额提供网络服务，套餐到期或余额不足时平台按预设规则提醒、限速或停机。空置状态下，房间没有住户，不应该保留活跃账号占用策略额度，历史账号在退租流程完成后应当转为停用或注销状态，避免旧账号被人捡起来继续使用。维修和清扫状态比较特殊：房间本身不能对外营业，但现场维修人员、保洁人员可能需要临时接入网络，这时可以在系统里设置临时访客账号或临时权限时段，维修结束自动失效，而不是把在租账号继续挂在这间房上计费。
退租状态要区分两个时点：租约结束时点和账号实际停用时点。人员离开后账号是立即停机、保留几天宽限期还是结清余额后注销，规则需要提前确定。平台支持账号暂停、停机保号、暂停消费等状态操作，也支持按套餐有效期和余额自动做停机检查，把房间状态和账号状态做规则映射后，日常运营就不用靠人工盯每个房间的变化。
换租和房间调整时，账号关系怎么转移
公寓运营中换租是高频动作：住户从三栋搬到五栋、从单间换到合租间、床位调整。建模时要提前考虑账号转移路径，而不是每次换租都销户重开。
在人为主的模型下，换租保留账号主体，只变更账号归属的房间、用户组和对应套餐。原房间的绑定信息解绑，新房间的绑定关系重新写入，历史账单保留在原账号下，住户不需要重新注册、重新实名。在房间为主的模型下，换租表现为新住户占用房间账号，原住户绑定解绑、新住户信息登记进房间账号，套餐是否延续由运营规则决定。无论哪种模型，转移动作都要留操作记录：谁在什么时间把哪个账号从哪个房间调整到哪个房间、余额和剩余套餐怎么处理。认证计费平台保留管理员操作记录、用户开户续费记录和上网记录，这些记录既是审计追溯的依据，也是换租纠纷时核对的材料。
跨楼栋、跨项目换租时，还要注意分组和策略的切换。不同楼栋可能配置了不同套餐、不同带宽策略和不同SSID，账号从旧分组移动到新分组后，平台按新分组的规则下发策略，转移过程中应当核对套餐归属、余额结转和绑定终端是否需要重新登记，避免账号人过去了、策略还留在旧分组里。
建模阶段容易漏掉的几个细节
第一个是房间层级与用户组层级对齐。楼栋、楼层、房间、床位在平台用户组里的层级关系，最好和租务台账里的编号规则保持一致，两套编号各用一套编码，后期核对时会非常痛苦。分组名称、房间编号一旦定下来，批量开户和后续统计都以这套编码为准。
第二个是空置房间不要留在活跃分组里持续产生数据。有些项目为了省事，退租后账号一直挂在房间分组里，既不上线也不停用，时间长了分组里堆着大量休眠账号，统计在线人数、终端数量和套餐分布都会失真。房间状态变化后，账号状态要同步变化。
第三个是维修、保洁、访客等临时人员与长住账号分开管理。临时账号单独建组，设置有效期和权限范围，到期自动失效，不要和长住账号混在同一组里计费统计。
第四个是房源变更要回到系统里更新。现实中房间合并、隔断改造、床位增加，租务台账改了，认证计费系统里的分组和账号归属没有同步，策略就会和实际房源脱节。建模不是一次性工作，房源结构变化时要同步维护系统里的数据关系。
小结
回到公寓日常运营，换租、退租、维修、对账这些动作之所以反复占用管理员精力，多半是前期数据模型没有理顺。账号以人还是以房间为主体，楼栋、楼层、房间、床位怎么归入用户组，空置、在租、维修、退租分别对应账号什么状态，这些关系在系统里定清楚，后续用户管理、状态控制、终端限制和记录审计才能自动跑起来，管理员不必在每一次人员变动时回头补录。不同公寓的房源结构和租约模式差别不小，模型选型、套餐分组和状态规则要对着现场台账和现有管理系统字段设计，照搬其他项目的配置往往会在换租环节暴露问题。