在大型高校、长周期运行的真实环境下，有些需求即便能做、也不该做；即便能上线，也不适合进入产品核心。

这些需求如果一开始不拒绝，几年后几乎一定会演变成稳定性、性能或运维灾难。

一、必须拒绝的第一类需求：把个性化逻辑塞进认证核心路径

这是校园网认证计费系统中风险最高的一类需求。

典型表述包括：

• 认证时根据复杂用户属性实时判断

• 认证过程中联动多套外部系统

• 在准入阶段执行复杂策略计算

从产品角度看，认证的唯一职责只有一个：
决定能不能上网。

任何试图把“业务判断”“个性化逻辑”“扩展功能”塞进认证核心路径的需求，在短期内可能满足个别场景，但在高并发、长期运行环境下，必然成为系统风险源。

蓝海卓越在校园网认证计费系统中，对认证路径有明确红线：
认证核心路径不承载任何非必要逻辑。

二、必须拒绝的第二类需求：认证与计费强实时、强一致绑定

在需求讨论阶段，经常会有人提出类似要求：

• 计费未完成不得放行

• 账务未写入不得上线

• 所有计费结果必须实时确认

从产品工程角度看，这是一个典型的“短期合理、长期危险”需求。

在真实高校环境中：

• 高峰期计费计算一定会放大系统压力

• 账务异常一定会发生

• 外部依赖一定会不稳定

如果认证必须等待计费完成，校园网认证计费系统在未来某个高峰时刻几乎必然出现“全体受影响”的情况。

因此，这类需求在产品层面必须被拒绝，或者被重构为认证与计费事件解耦。

三、必须拒绝的第三类需求：无限灵活、无边界的策略体系

“策略越灵活越好”，是很多项目初期最容易被接受的一句话。

但在校园网认证计费系统的真实运行中，这往往意味着：

• 策略嵌套不可控

• 行为路径不可预测

• 运维人员不敢调整

从产品角度看，一个健康的策略体系应该是：

• 有明确边界

• 有固定执行顺序

• 有可预测结果

蓝海卓越在校园网认证计费系统中，对策略功能做了产品级约束，宁愿拒绝部分极端灵活需求，也不引入长期运行风险。

四、必须拒绝的第四类需求：所有数据都要“实时统计、实时展示”

数据需求在校园网认证计费系统中非常常见，但风险同样很高。

典型需求包括：

• 所有数据实时刷新

• 报表必须实时更新

• 历史数据实时参与统计

从产品工程角度看，这是一个典型的性能陷阱。

在大型高校环境中，数据量只会不断增长，如果实时统计逻辑反向影响认证或会话管理，系统稳定性迟早会被拖垮。

蓝海卓越在校园网认证计费系统中，坚持一个底线：
数据分析必须异步，统计不能影响实时业务。

五、必须拒绝的第五类需求：多校区“完全共享、毫无隔离”

在教育集团或多校区高校项目中，经常会出现这样的需求：

• 所有校区完全统一

• 所有策略全局生效

• 所有数据集中处理

从产品稳定性角度看，这是一个结构性风险需求。

一旦出现：

• 单校区异常

• 配置误操作

• 局部流量失控

整个校园网认证计费系统都会被牵连。

因此，从产品层面必须坚持：

• 校区逻辑隔离

• 会话隔离

• 策略作用范围可控

这类“集中化过度”的需求，必须在一开始就被拒绝或重构。

六、必须拒绝的第六类需求：依赖外部系统作为实时关键路径

在实际项目中，常见需求还包括：

• 认证时强依赖第三方接口

• 实时调用教务、财务、身份系统

• 外部系统异常即认证失败

从产品工程角度看，这是把系统稳定性交给别人。

外部系统的稳定性、性能、维护窗口，都不在校园网认证计费系统可控范围内。

蓝海卓越在产品设计中，对这类需求的处理原则非常明确：

• 外部系统只能作为辅助

• 不进入实时认证路径

• 异常必须可降级

否则，这类需求一旦上线，后期几乎必然成为事故源。

七、必须拒绝的第七类需求：为极端个例定制核心逻辑

在高校项目中，总会出现：

• “只有一个学院这样用”

• “只有少数用户需要”

• “以前系统就是这么做的”

如果为了这些极端个例去修改校园网认证计费系统的核心逻辑，长期来看一定得不偿失。

蓝海卓越在产品层面非常清楚地区分：

• 核心能力

• 可扩展能力

• 项目级定制

核心逻辑必须保持稳定，不为极端场景破坏产品结构。

八、为什么敢拒绝，是产品成熟度的体现

很多系统之所以在运行几年后问题频发，并不是技术能力不够，而是一开始什么需求都答应了。

校园网认证计费系统在大型高校环境中，是一个需要长期稳定运行的工程产品，而不是一次性交付的软件项目。

蓝海卓越 21 年专注网络认证、计费与准入控制，在产品层面敢于拒绝高风险需求，正是因为这些需求在真实运行环境中已经被反复验证过后果。

一个真正成熟的校园网认证计费系统，往往具备一个共同特征：

它非常清楚自己不该做什么。