见过不少学校在选型时，拿着招标需求文件一条一条核对功能：有没有Portal认证，有没有套餐自定义，有没有多运营商接入，有没有设备绑定管理，有没有财务对账模块，有没有等保合规日志。每一条都有，评标得分很高，中标之后实施阶段才发现，系统确实是"全"的，但有些功能是残次品，有些功能上线三年从来没人用，有些功能之间的逻辑互相打架。比如一个案例：某校的计费系统同时支持按流量计费和按时长计费，但两套计费规则在学生切换接入方式时会出现重复扣费，因为两个规则是分别独立计费的，系统没有做互斥判断。这个问题在功能清单里完全看不出来，只有在学生真正混合使用有线和无线两种接入方式时才会暴露。而这类暴露往往是在上线几个月之后。

校园上网计费系统的功能丰富度和技术成熟度之间，往往存在张力。一个在行业里做了十几年的厂商，功能可能没有那么多，但每条链路都踩过坑，知道哪些地方容易出问题，系统的边界在哪里。另一个新进入市场的厂商，功能清单可能有二十多条，但真正落地稳定运行的只有五六条，剩余的功能要么是demo演示用的，要么是后期规划但还没有完全实现的。评标时功能数量占优，交付时才发现稳定性差距有多大。

选型时最值得关注的，不是功能数量，而是核心链路的实际表现。认证成功率和充值到账延迟是两个最应该实测的指标。认证成功率不能只看系统日志里的汇总数字，要看：高峰期并发认证时成功率是否下降，降幅是多少；学生切换接入点重新认证时是否会出现异常状态，比如MAC地址绑定校验失败；代拨模式下运营商侧账号同步失败后的降级表现是什么，是阻断还是放通。充值延迟也是同理，要看充值完成到上网策略刷新之间，在不同并发量下的实际延迟分布——平均延迟可能只有几秒，但P99延迟（99分位）可能高达几分钟。厂商在PPT里写的"秒级响应"指的通常是平均值，而不是最坏情况。

还有一个容易被功能清单误导的地方：多运营商代拨。有些学校的计费系统支持"多运营商"，但落地方式是每个运营商单独配置一套账号体系，学生需要分别注册和充值。这种方式在功能清单里可以声称"支持多运营商"，但实际上学生需要管理多套账号，使用体验差，投诉量会明显上升。真正的多运营商代拨，应该是学生只需维护一个校园账号，账号背后绑定某个运营商的套餐，后台自动完成代拨拨号，学生对这个过程完全无感知。运营商侧的账号创建、套餐变更、代拨失败处理，全部在后台完成。这个架构的实现难度远高于"多套账号体系"，不是每个声称支持的厂商都能做到的。判断方法是问厂商要一个同时跑了三家运营商的真实案例，让他们提供对接了三家运营商的BRAS设备型号和账号同步机制的技术说明。

财务对账模块也是一个典型的"看起来有"和"真正好用"差距很大的功能。很多系统的财务对账是指：计费系统里能导出一份Excel，包含充值流水和消费记录。但这份Excel和学校财务系统的实际入账之间，还隔着：对账时间差——充值成功时间和财务系统入账时间可能不一致；退费冲减——学生退费时余额如何从财务系统里核销；支付宝微信的提现手续费处理——充值渠道收取的手续费是否需要单独做账；不同充值渠道的到账确认机制——一卡通充值和第三方支付的对账逻辑不同。如果计费系统没有这些场景的处理能力，财务对账模块在投标文件里可能写得非常完整，但实际用起来还是一堆手工操作。

评估功能成熟度，有一个简单的办法：让厂商提供他们最近一个已完成的项目，让学校直接联系那个项目的网络中心主任，问三个问题。这三个问题是：这套系统上线后，日常运维里最占用时间的是哪类问题？你们有没有遇到过系统本身的问题导致的大规模投诉？如果现在重新选型，你会在哪些地方重点考察？这三个问题比任何demo和PPT都有说服力，能问出很多PPT里看不到的东西。

功能全不等于好用。选型时把核心功能的实测数据列清楚，把落地场景的判断题问到位，比对着功能清单打勾更有价值。真正跑过项目的经验，才知道哪些功能是核心，哪些功能是装饰。