做过几轮认证计费系统采购的人都知道，招标文件里的技术参数表看起来一个个都满足，但等系统到了实际场景里，总有几项跑不起来或者达不到宣传的效果。这不是偶然，有几类参数在整个行业里写虚现象都比较普遍，值得在起草招标文件或评标时特别留意。

第一类容易写虚的是并发认证能力。招标文件里经常出现"每秒支持N次认证"这样的参数要求，但这个数字在什么条件下测出来的，很少有厂商会主动说清楚。Portal认证的处理能力受服务器硬件配置、数据库响应速度、网络延迟等多重因素影响，在厂商自己的测试环境里跑出的数字，和在实际部署环境里的表现可能有较大差异。更合理的写法是要求厂商提供在指定硬件配置下的测试报告，并约定上线后的压力测试验收条件，而不是只写一个数字。

第二类是"支持N家厂商设备"的兼容性参数。说支持华为、中兴、H3C、锐捷、思科等主流厂商，听起来覆盖面很广。但支持是指全系列产品还是部分型号？对接的是哪个协议版本？有没有经过实际测试？这里面的水分可以很大。有些厂商的设备在不同固件版本下对RADIUS的实现有差异，某个型号的设备在某个固件版本下能正常认证，换了另一个版本就出问题。招标时应该要求厂商列出经过实际测试验证的设备型号清单，而不是笼统写"支持主流厂商"。

第三类是高可用和容灾能力。"支持双机热备"在很多招标文件里是必选项，但实际上双机热备的实现方式差别很大。有些系统的双机热备只是主备切换，切换时会有数秒甚至更长的认证中断；有些实现了会话同步，切换后在线用户不掉线；还有些所谓的"热备"实际上是冷备，切换要靠人工干预。这几种情况下用户体验的差异是很显著的。招标时应该明确要求：主备切换后在线用户是否需要重新认证、切换时间不超过多少秒，以及提供同类项目的验收记录作为证明。

第四类是系统的扩展性参数。"支持横向扩容""支持分布式部署"这类描述，几乎每家厂商的产品文档里都有，但扩容的操作是什么？需要停机吗？扩容后的数据一致性怎么保证？新节点加入时在线用户受不受影响？这些细节在招标文件里通常不会写，等到真正需要扩容时才发现过程远比想象中复杂。对于有明确扩容预期的项目，招标时就应该把扩容流程作为必测项列进去。

第五类是日志留存能力。公安备案要求保留用户上网日志不少于180天，这几乎是所有认证计费系统招标的标配要求。问题在于：日志留存的字段是否完整（包括用户标识、终端MAC、接入位置、上下线时间、流量）？日志是否可以按需查询和导出？日志存储满了之后的处理策略是什么？这些细节决定了日志在实际合规检查时能不能用，而不只是系统里有没有存一份。如果日志字段不完整或者查询功能欠缺，合规审计时就会出问题。

第六类是响应时间的SLA承诺。技术服务和售后支持部分经常出现"7×24小时响应""远程支持响应时间不超过N小时"的描述。这里的响应是指电话接通还是问题解决？如果只是接通电话算响应，这个承诺的实质价值很有限。应该要求区分不同级别故障的响应时间和解决时间，比如全网认证中断属于紧急故障，要求N分钟内远程介入，N小时内恢复正常。

招标参数的核心是要可验证、可量化，避免模糊描述给厂商留太多解释空间。在评标阶段对重点参数做现场演示或要求提供真实案例的验收报告，是减少水分的有效手段。

还有一类参数是"升级服务保障"。招标文件里通常要求厂商提供几年的免费升级支持，但升级的范围是什么？只包含漏洞修复，还是包含功能新增？升级需要停机吗？停机时间多长？数据在升级过程中的安全性如何保证？这些细节决定了未来几年用户端的实际体验，而不只是一句"提供3年升级服务"所能涵盖的。

最后一点是招标参数和验收标准的一致性。很多项目的招标技术参数写得很全，但验收阶段的测试项目却只测了几个基本功能，大量技术参数没有对应的验收用例。这就给了厂商操作空间——招标时承诺了，验收时没测到，后续出了问题就变成争议。建议在招标文件起草时，同步设计验收测试用例，每一个关键参数都有对应的测试场景和验收通过标准，让招标参数和验收标准形成完整的闭环。