根据 https://www.cnblogs.com/clwydjgs/p/9317849.html：

在 @Transactional 注解中如果不配置 rollbackFor 属性,那么事物只会在遇到 RuntimeException 的时候才会回滚,加上 rollbackFor=Exception.class,可以让事物在遇到非运行时异常时也回滚。

可以理解是，假设你始终使用 RuntimeException （遵循 kotlin 和 C#的风格），那么就只需要用 @Transactional 。我的建议是：Exception 有害，请遵循 kotlin 和 C#的风格。

《计算机网络》谢希仁

你要看是什么层面的 0day bug 。如果是文件系统管理代码的 bug，那么就可能是核弹。如果只是资源管理器的，就只是影响体验的 bug 。

先把它带回住所，看看亲不亲人。如果不是流浪猫，基本别指望它亲人。

还有一个建议：用某种 profiler 看看到底哪些函数是罪魁祸首，方便定位问题

建议楼主把代码贴出来，给大家一个最小的可重现的代码，既方便大家调试，也方便排除其他问题。
还有就是楼主一些地方的表述不太清晰，可能会让项目成员以外的路人产生困惑。例如“随着循环时间越来越长, 解析 B 类文件数据的这个函数执行会越来越慢”

@avastms 还真有你说的那种完全“云化”的数据库）。
对象储存勉强算一种。此外，还有如下的：
AWS DynamoDB, Azure CosmosDB, Google FireStore, 阿里云 Lindom Serverless

如果有神经网络的基础，有部署能力，可以考虑开源的模型。

如果想 100%开箱即用，如果 github 上没有找到能开箱即用的，就只有用百度之类的服务。

别想了，5 年后最火的岗位，现在还未被命名。

不是师傅的问题，而是人的本质问题。

只有 2 种东西会成为动力：

1. 对学习的内容感兴趣
2. 被迫学习

把电影看一遍，写一篇影评或感想。mkv->docx 。

- 使用 Git 对 xml 城市数据进行版本管理。对它的修改也要通过版本管理控制。对于这种不常变动的信息，可以充分发挥 Git 的优势。

- 开发同步程序，能够实现在改动后，将 xml 的城市数据同步到数据库。

- 如果后面由于业务的演化，还想要更强的定制性，那么就不要让同步程序直接访问数据库，而是开发一个 Rest 的服务。这样，就产生了 2 个微服务，其中，同步服务通过 Restful 接口将信息传递给主服务。

2 个微服务的优势是：如果需要收集更加全面的城市信息，只需要在保证接口的情况下，将城市信息服务的摊子丢给其他人，提升开发效率。

---

我之前开发的一个柯南追剧的网站（自己用）就存在和你类似的需求。
1000+集柯南（每周六从 wiki 挂 vpn 手动获取）、剧场版和 OVA （每年手动填写 csv 表格）。这些不同的数据源都通过单独的服务进行管理，而无需将逻辑泄露给主服务。以上的建议也是基于我在这里的实践经验提出。

卧槽，好险好险。我昨天晚上想下个手机版的币安，由于是华为所以 google play 用不了，所以就想通过 apkpure 下载。最后幸好看到了直接的 APK 链接。

读多写少：MySQL
读少写多：MySQL

业务量大：选择比关系型数据库更适合的

中国大学 MOOC 数据库系统概论 基础篇、数据库系统概论 高级篇。

必须在函数开头检查引用是否为 null，这是最基础的编程常识。这样就可以区分是调用者出了问题，传入了 null，还是函数体有 bug，在中途访问了 null 。bug 就被局限在小范围内，而不是跨函数找 bug 。

除此之外，没有代码上下文，唯一可能出问题的就是把 IOException 掩盖掉的问题。


@guyeu C# visual studio 对传入参数的代码建议也包含 if(x == null) throw new NullReferenceException(nameof(x))，和 java 的思想一致。

IEEE754

涉密数据用开源的 Keepass 发行版解决，Keepass 可以选择上云（配合坚果云使用），但是是加密后上云。

@binux 阿里规约指的是设计者主动抛出异常的情况吧。