是的，react 的生态会略微好一些，在做 markdown 解析器遇到过跟你类似的问题。

恭喜😊

被人认可的喜悦ヽ(✿ﾟ▽ﾟ)ノ

别擦，擦红了就用红霉素眼膏敷一下，提升一下环境湿度有助于缓解疼痛，建议纸卷成卷塞鼻子里（等同流鼻血处理方式）

用 netch 走系统路由层代理

执行在用户控制的设备上，无解，只能尽可能提升难度（闭源和混淆是一般操作）
把重要逻辑搬到服务器上吧
一些不大现实的方法：
在用户设备可信执行环境中执行，参考 Android 上 DRM 的实现
使用同态加密

找个老师傅带带？画 pcb 感觉经验性的东西更多一些。
qwq ，我画板子都是直接抄芯片 datasheet ，application note 上有参考电路图，点名表扬 TI 的电源芯片文档，pcb 布局上的要点说的很清楚。
供参考~

太厉害了😮

好项目，赞

补充一条，chrome f12 进 devtool 切换到 security 标签页可以看到当前 https 使用的加密算法集

生日快乐🎂

考虑场景：一般情况下，用户是长期登录的，而且认证信息不会被轻易被盗，但是仍然存在一部分用户有登出账户的需求（手机被丢等）。
相对于当前长期在线的用户而言，需要登出的用户只是很少的一部分。（这跟现在的证书颁发是很相似的，大多数人都会妥善存储私钥，但是仍然有一部分人的私钥马大哈丢失了）

这时候可以使用 jwt 作为用户令牌，使用 redis 等来存储被吊销的 jwt id 。
这样做主要是可以有效的减少热数据的数据库大小，降低对数据库系统的压力。而且，这个吊销列表也完全没有必要实时更新，隔一段时间向认证服务器更新一下数据即可。

如果你的应用用户量并不是很大，或者对登出的实时性要求很高（银行类），jwt 其实并不是一个适合你的方案，随机生成一个 token 可能更好。

遇到过类似的问题，移动宽带的 ipv6 好像有连通性问题，遇到这种情况我一般都是重新拨号一下。让两端的地址换一下。

如果正常的网页内容，推荐使用反代，对用户，对搜索引擎都友好。
如果是大量数据传输的，推荐走非常规协议，自己写一个客户端，如果一定要 web 的话，用 webrtc 。
再多嘴一句，面对大陆用户的任何形式服务，如果想要做大，做正式，请走合规途径（备案），监管机构不是吃干饭的，你服务器到用户的路径上，如果是合规的，那一定会有三大运营商，他们想搞你不是能不能的问题，是想不想的问题。

新年快乐

好像跟梯子的 ip 有关，不行的话试试换个代理。