转行脱产还建议一下 你这都是开发岗位了没必要
边上班边学习也是可以的啊 Nginx 还不是上班时间搞出来的项目

先看个公钥和私钥的公式
第一步，随机选择两个不相等的质数 p 和 q 。
第二步，计算 p 和 q 的乘积 n 。
第三步，计算 n 的欧拉函数φ(n)。
第四步，随机选择一个整数 e ，条件是 1< e < φ(n)，且 e 与φ(n) 互质。（常常选择 65537 ）
第五步，计算 e 对于φ(n)的模反元素 d 。
第六步，将 n 和 e 封装成公钥，n 和 d 封装成私钥。

在实际使用中 e 是常量也就是 65537 因此有了私钥也就推导出了公钥 不支持私钥加密应该是为了安全考虑

内容加密场景是 我发出去的消息 只有对方能解 所以用公钥加密
签名的场景是 我发出的消息并且把公钥发给对方 对方要用公钥认证是我发出去的消息 如果发送的是私钥的话 公钥也就暴露了

iphone4s 还是 32 位的系统 现在你环境都不一定搭起来

可以看看 opentracing 规范

实现起来也很简单,golang 的话 gin 写个 middleware 也很快,java 拦截器里实现也快
研究过客户端的逆向，现在除了 flutter 不好逆向外，其他很快就可以逆向出密钥了，就像 4 楼所说，加密只是增加破解时间。

假基站发的？

只是查余额转账还信用卡的话 可以用云闪付

建议先抓个包 然后根据参数分析一下

苏宁送两年

装个 wireshark 抓 loopback 的包

有可能是朋友圈的小视频阻止了锁屏

iOS appstore 的包也是对代码加密的啊，但是照样可以通过砸壳的方式分析，只要代码跑在客户端，就有被分析的可能。
只要接口可以被公网访问，就有安全风险，所以最主要的还是需要后端去做安全方面的防护。

我感觉 jwt 最合适的场景是开放平台，开发平台向三方应用颁发应用颁发 jwt token,token 中的 payload 携带用户 id，应用权限等信息，这样只需要验证 token 的签名就能做好用户对个接口的访问权限。
比如 a 应用有 profile,email 的权限，而用户使用 a 应用的时候只同意了 profile 的权限，这样服务端颁发的 jwt token 的权限列表中就不包含 email，那么 a 应用就算在 token 的 payload 增加了 email 权限，但是由于签名的存在，篡改是不生效的，而且还减少了服务端通过数据库验证 token 权限的操作。

以前的 flash 算不算？

之前经常无响应 后面把 QQ 缓存全清了就好了