SecureView在单人演示时，最容易看见的是加密上传、分享和解密。但项目做到后面，我花了更多时间在没那么显眼的地方：数据库连接、并发请求和失败后的恢复。

这是我们四人的毕业设计。我负责的部分包括测试、CI、部署和一些安全功能。加密文件分享不仅要保证算法正确，还要保证请求多的时候不会把数据库卡死。

上传失败不一定是加密出错

我们做过多人并发的容量测试，发现100用户场景下数据库连接池的问题。上传失败率一度很高，排查后修复了连接池故障；项目README里保留了对应的测试记录。这里不重新给出没有运行过的新基准。

同一类问题还包括MySQL并发死锁。错误不一定出现在最复杂的业务逻辑里，有时是多个请求以不同顺序争抢行锁。只测试一次上传成功，完全看不出这些路径。

我后来更依赖回归测试

修复以后，应该留下能够复现故障的测试，而不是只在本地重试几次就算解决。MySQL相关测试、真实浏览器流程和故障注入，都是为了让今后的改动不要把同类问题带回来。

数据库问题不宜只凭一个错误码下结论。要看具体事务、锁顺序、超时和重试边界，尤其不能对结果未知的写操作无限重试。

项目的具体环境、历史测试数字与限制，都放在SecureView仓库。这篇文章只是整理为什么需要并发测试，不等于对当前线上环境重新做过性能验收。