kaneg

可以查看一下几点：
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 ）都是相同的。