透过现象看本质，关键是看你手头的现金的投资回报率与银行的利息哪个高。如果回报率比利息低，就跟前面 @jupiter157 说的，那就等效于借了银行的钱又存银行，白白给银行利息，这就是为银行学雷锋。

说明你们公司的客户不多。
要考虑多客户的设计应该是代码保持同一份，客户的不同需求靠各自的配置来适配。

能用 POST 不让用 PUT 就是掩耳盗铃

如果要限流，可以用 resilience 方面的库来做，可以限制并发，限制时间段内访问的次数，错误超过设定后丢弃部分请求等。比如 Java 的 resilience4j.

可以查看一下几点：
1. 下载还是上传？上传与下载带宽可能不对等
2. 看服务端和客户端的 CPU 占用率
3. 用其他工具来确认服务端和客户端直接的带宽是否只有 20M
4. 是否文件读写是被磁盘速度限制。老一点的机械硬盘也就这个速度

如果已经 push 了，正规途径已经无法更改。除非你获取篡改历史的权限：force push 。

我看到过很多人把 git 的 commit 当成草稿箱，提交很多无意义的改动，每次 commit 基本在修改错别字或者反复 rollback 。针对这种情况，在 PR merge 到 master 之前，最好 squash 。否则如果日后做 trouble shooting 的时候，其中的每条 commit 就是对别人的折磨。

证书 copy 一份到 nobody 能读到的地方很难吗？

最近在搞后端 API 的聚合，也有楼主一样的纠结。如果分多个 API，UI 写的代码就比较，维护起来也麻烦；如果全放后端，又会降低灵活性。

不过多个调用能并发的，前端和后端都能做。

直接调 read （）方法啊，它会自己阻塞直到有数据才返回。

再等几天直接上 Java17，是个长期支持版本，起码未来 5 年都不用考虑升级的问题了。

所以，很多人为了所谓的灵活，并且懒得定义 bean class，结果自己一时爽，😭了后来人。

@lcdtyph,是的，这个题目中密钥，明文，还有 e (可以推算出等于 17 ）都是相同的。

user id 这种不敏感的信息存在 session 是正常的做法。

看最后的 flag，这是一道 CTF 的题目，类似的题目之前做过。用中国剩余定理可解。

flag{7189cb408174df02ebeae57c4d3ac0e0}

无状态的好做，有状态的难，比如数据库，文件系统。
如果数据层面能做到新旧代码都兼容还好，如果不兼容那就会出现意想不到的结果。

可以试试阿里云的 nas 。它的 nas 分为两种，一种是容量型的，延迟好像是数十毫秒。另一种是极速型，延迟几毫秒，可以用做数据库，不过就是价格比较贵。

被 Google authenticator 坑，你不是一个人。