CICD 自动构建不就好了吗？为什么还要手动部署？

同意啊， 已经很明显出现了奔溃的现象， 还在想着没必要加入回归测试，我没办法理解。
所谓回归测试，就是即使没有任何改动，也要去回归一遍， 保证功能正常。 因为就算没有代码的改动，也不能保证所有的依赖（服务器，操作系统，浏览器等等）可能的变化对功能的影响。

这其实是你们的策略制定的出发点是什么， 如果说纯粹从技术角度来看， 没问题；
但是从质量管理的角度来看， 已经有客户会在实际使用的时候遇到这种奔溃的问题，而且从你的描述来看，不是随机的小概率事件，而是某些功能你们选择性地不去回归，没有发现问题。

如果是新功能影响到的老功能，说明你们的回归测试策略不完整。
有没有必要都放到回归测试里面，是基于风险去评估的， 很明显你们现在的情况就是需要加上。

1. 如果奔溃是功能性产生的，可以考虑跑个 monkey 测试之类的， 多覆盖一些随机的操作
2. 如果奔溃是跟设备兼容性相关的， 检查一下兼容性的测试策略， 还有找云测平台跑一下不同的设备。
3. 做好奔溃日志收集，定期检查分析，找出可能存在的问题。

每个行业都有历史发展的过程啊， IBM 小型机在某个时间就是处理这种业务的最好选择，很多银行系统都是沿用到现在。

你把读出来的每个 row 打印出来就知道了 ， 自己调试一下吧。
先把这个 get data 的方法给调通。

你需要的是列表，但是直接从 CSV 文件里面读取出来的就是一行字符串啊， 所以你要通过逗号去 split 成列表。

你每一行数据读取出来好像还是作为一个字符串来处理的， 应该要按逗号做一下分割，匹配到三个字段里面？

你想想几个场景：

1. 你在玩对一款游戏，每个月会停服 8 小时更新一次。你希望是在白天停服， 让你玩不了，还是希望它在半夜停服，反正对你没影响？
2. 你是一家超市的老板，每个月要停电 8 小时做一次线路检查。 你希望是一个白天关门不做生意， 还是让一些员工在晚上加班去完成检查， 不影响白天营业？

所以发版这个事情从来都是以尽量不影响用户，或者对用户影响尽量小的原则去规划的啊， 员工要定期晚上加班去支持发版， 只是这份工作的其中一个特殊性。 人家医院的医生护士还得三班倒值夜班呢。

PS 白天发版还是晚上发版，跟是不是自研没关系， 只是看你的用户量和访问量。 除非你们老板够牛，我就不喜欢加班，用户用不了就用不了咯。