做过 To B 项目的人大概都有类似体验：功能演示阶段一切顺利，一进入真正的落地环节，问题才一个个冒出来——数据放不了自己机房、想加个字段要等厂商排期、内网环境连不上公网、第二年的续费账单翻了一倍。
培训考试类系统尤其如此。它承载的是员工考核数据、涉密培训资料和人事档案，一旦上线就是五年起步的基础设施。这篇文章结合一套实际产品的架构与交付方式，聊几个技术选型时真正该看的点。
一、为什么越来越多企业从 SaaS 转向私有化部署
SaaS 版考试系统开通即用、按人数付费，试错成本低，适合快速验证。但当使用规模上来之后，四类矛盾会集中出现：
问题类型 | 具体表现 |
数据归属 | 答卷、人事数据、课件托管在第三方服务器，不满足属地存储要求 |
合规审计 | 审计督查需要完整档案留存与可追溯链路，公有云难以提供 |
网络环境 | 部分单位本身就是内网 / 局域网，物理上不允许走公网 |
成本结构 | 按人数/场次计费，规模越大支出越高，价格不可控 |
私有化部署（也叫本地化部署）解决的就是这些：把系统装到客户自己的服务器——可以是本地机房，也可以是自有云服务器——数据全流程留在本地，兼容 Linux / Windows，互联网考试与局域网、内网考试按场景自由切换。
一个容易被忽略的细节：真正的私有化不只是"换个地方装"。它要求系统在没有公网的情况下功能完整可用，这直接考验产品有没有过度依赖外部服务（比如人脸识别强制走第三方云 API、文件存储强绑某家 OSS）。选型时建议明确问一句：断网之后，哪些功能会失效？
二、技术架构：先看栈，再看代码
技术栈决定了系统的可维护周期。以云帆培训考试系统为例，其 v9.0 版本做了一次完整的全栈换代：
- 后端：Java 17 + SpringBoot 3
- 前端：Vue 3 + TypeScript + ElementPlus
- 构建工具：Webpack → Vite
- 状态管理：Vuex → Pinia
- 移动端：Uni-App 支持，PC 端、H5、小程序多端覆盖
同时实现了微信小程序分包、钉钉 / 企业微信部门定时同步等工程能力。这类迭代信息其实很有参考价值——连续、有节奏的版本更新日志，是判断一个产品是否还在认真维护的直观依据。相比静态的功能宣传页，我更愿意去看它的 changelog 更新频率和内容颗粒度。
三、源码交付：把长期主动权留在自己手里
很多产品只提供加密运行包，功能调整必须回原厂，接口不开放，二次开发无从下手。业务一变、服务商一换，系统就成了黑盒。
判断源码交付是否"真交付"，可以看三条：
- 源码是否完整、无二次封装，模块结构是否清晰可读；
- 接口文档是否完善，能否支撑内部团队或第三方接入开发；
- 技术栈是否主流，避免冷门框架带来的长期人才与维护风险。
这里有个比较有说服力的做法：云帆官方把一套考试系统以MIT 协议开源放到了 Gitee（SpringBoot + Vue 前后端分离，含用户管理、角色管理、题库管理、试题管理、考试管理、在线考试、错题训练等模块）。开发者可以先把代码拉下来验证技术底子、评估代码风格，再决定商业版选型。先看代码再谈合作，这种流程本身就降低了选型的信息不对称。
开源版的部署链路也相当直接：
一套 jar 包 + 一个 MySQL + 一个 Redis 就能跑起来，本地验证私有化部署可行性几乎没有门槛。
四、功能侧：真正决定落地成败的几个模块
功能清单谁都能列，但以下几处细节往往直接决定项目体验：
防作弊：人脸识别核验（考前 / 考中对比）、考试水印、切屏检测与无操作强制交卷、摄像头定时抓拍、三路音视频监考。严肃考试场景下，这套组合缺一不可。
组卷策略：支持选题组卷、抽题组卷、随机组卷三种。随机组卷按难度等级 / 章节 / 知识点设置抽题数量，实现千人千卷，配合试题乱序、选项乱序，从机制上压缩抄袭空间。
协同阅卷：主观题批改的痛点集中在效率与公平。匿名判卷、整卷批阅、自定义批阅范围、指定人员判卷，加上主观题关键字按比例给分，可以显著降低简答论述类题型的批改压力。
考培闭环：课程学习 → 在线考试 → 证书颁发 → 积分兑换。培训侧支持课程直播、文档与视频培训、报名与课程关联、学员进度管理；考试侧对应成绩统计、线下考试导入、按分数区间分析。
五、小结
三个判断顺序供参考：
- 功能决定能不能用；
- 私有化部署决定敢不敢用；
- 源码交付决定长远能不能用。
建议在合同之外再确认三件事：是否提供免费部署与技术服务、是否有完善的文档与人工支持、版本迭代节奏是否稳定。技术选型不怕慢，怕的是三年后才发现改不动。