@456vv #47 还真不一样。从攻击面的角度来说，密码在网上传输的次数越多，承担的风险越大。
登录这个过程，用户名和密码必须要通过网络传输，这没办法。但登录后获取 token 的意义就在于，避免后续再传密码了，用 token 来充当用户名+密码。
但如果 token 是固定不变的，那也没意义了，和 basic auth 一样，并不安全，所以 token 必须要经常变。
token 当然不用是一次性的，但是必须要有时效性，定期续期，并且时效性越短越安全。比如银行网站就可能会要求 5 分钟不操作自动退出。
用 token 来代替密码就是为了频繁更新，避免同一套字符串一直在网上传。

所以，比较推荐的做法是，密码登录，换取两个 token ，一个是有较短时效的 session token ，一个是有较长时效但是一次性的 refresh token ，然后用 session token 通信，session token 过期后，再用 refresh token 获取两个新的 token 。
这样，密码因为更新频率很低，并且长度通常相对较短，所以只在网上传输一次。refresh token 因为可以充当密码来获取新的 token ，所以只在网上传输两次（往返各一次）。session token 权限最低，只能在有限时间内使用，且不能充当密码来获取新 token ，泄漏后的影响也是有时效性的，用来进行低频敏感操作可能还会要求用密码来做二次认证。
如果存在攻击者，那么他必须精准地获取登录包或者是 refresh token 的数据包，才可以拥有较高的权限，但这样的数据在网上传输的频率非常低。那么这个攻击者就必须长期攻击监控这个用户，那被用户发现的概率就提高了，而且大概率还只能拿到 refresh token 跟用户抢续期权，用户更容易发现账号被盗。

@kevinwu04266 标准 https 端口就是 443 ，http 就是 80 ，你用其他端口就是非标准。
浏览器怎么知道你用的哪个端口，你总不能让浏览器去猜吧？肯定是得要你自己明确指定啊！

子组件获取祖先组件的数据，这个逻辑没有问题，props/context 往下传都行。子组件存在的前提肯定是所有祖先组件都挂载存在了。
但是祖先组件获取子组件的数据、兄弟组件之间获取数据，这个有一个问题是，你要获取数据的那个组件可能不存在。
而你现在这个问题，综合了获取兄弟组件、子组件数据的情况。
你提到了“按照以往非组件化的思路应该是直接获取到这个 grid 对象，在调用对应的 getValue 方法就可以了”，这个在 React 中对应的就是 ref ，ref 上暴露 getValue 方法就是你说的这个了。函数组件没有对象实例可以用 React 提供的 forwardRef 。但是你也得要考虑一个事情是，这个实例引用变量存放在哪里，怎么去获取。因为这个 ref 的持有人默认只有挂载这个子组件的那个父组件，你又得要想办法把这个 ref 传给祖先、兄弟。
所以，这个 ref 的最佳存放位置就是共同祖先上，然后通过 context 往下传。但既然到了共同祖先这一步，那么就不要存 ref 了嘛，直接存数据就好？这就是楼上提到的数据存在共同祖先上，然后下面用 context 来读写数据。
祖先上不管是存数据还是存 ref 都是有自己的实际场景的。如果要调用对应组件的 API ，就还是得存 ref 。
然后另一个方案，全局状态，这个实际上也是把数据存在祖先上，只不过是存在根祖先上，子孙组件通过封装过的 context 读写数据。

不管是用全局状态还是自己写 context ，本质上都是数据存在祖先上，你在读取的时候不需要关心目标组件是否已经挂载存在，没挂载存在的话，你读到的就是个默认值。

或者楼上也有提到全局的通知广播，但这个一旦滥用就不好控制了。React 18 里有个 API ，useSyncExternalStore ，实际上也可以实现跨组件的共享，因为本质上数据是脱离 React 存在的，一个 store 实例，一个组件更新，一个组件监听，相当于一个小型的受限的广播系统，会比全局的广播好一些。

windows 的话，桌面上新建个快捷方式，路径填写 python 脚本路径，然后快捷方式右键属性能设置快捷键

不知道你的 aHandle 和 bHandle 的具体逻辑，不过仅目前的这段代码的逻辑来说，按照我的思路，我会把 aHandle 和 bHandle 直接写成 useEffect 。
useEffect(() => {
if (type !== aaa) return;
// aHandle 的函数体，直接处理，而不是调函数
}, [type]);
useEffect(() => {
if (type !== bbb) return;
// bHandle 的函数体，如果要异步处理，就立即执行包一下
let cancel = false;
(async () => {
await xxx;
if (cancel) {
return;
}
//...
})();
return () => {
cancel = true;
};
}, [type]);

好好好，你们都禁用传感器权限是吧，这就回去改。
倒计时 3 秒跳转广告，摇一摇取消跳转。
然后给你 摇一摇跳转、摇一摇取消 两个随机轮换着出。
这样，阁下该如何应对？🐶

有没有一种可能，dig 用的系统 DNS 解析，返回的 IP 被 SNI 墙，ICMP 能通，TLS SNI 不通。
浏览器配置 DoH 之后，强制走了 DoH 来解析，Cloudflare 的 DNS 因为隐私问题所以不支持 EDNS Client Subnet ，解析到的 IP 和你 dig 的不一样，解析到一个没被墙的 IP ？

还有些网站会看 TLS 指纹

用过 gitlab PC 网页版编辑器，在手机上改代码，提 MR 。
只能说，手机适配了，但又没完全适配，能写，但只能写一点点，不能写多咯。
关掉手机的旋转锁定，有时需要竖屏，有时需要横屏，不然点不到。新建分支，打开指定目录下的文件，修改，提交 commit ，提交 MR ，整个流程都能走下来，最终任务是完成了。
只能说，临时应急改代码提交，问题不大。

办二代身份证我记得是要等 20 天才能做出来吧？不过应该能加急

@Anonono #11 #12 我注意到 nginx 文档中有一句 The code 308 was not treated as a redirect until version 1.13.0. 也就是说，308 状态码是 nginx 1.13.0 才支持的，查了下 nginx 的更新记录，1.13.0 是 2017 年 4 月 25 发布的。而那个评论的时间是 2015 年 2 月 4 日。
所以评论者当时的 nginx 版本只支持 307 （ 2012 年 2 月 29 日的 1.1.16 和 2012 年 3 月 5 日的 1.0.13 ）。评论者的原话是 That way the request method isn't auto converted to a GET as is default 。所以 301 估计就是那个人自己加的，用于避免请求方法被改成 GET 用的，与原题无关，但推荐一块加上？
现在版本的 nginx 支持 308 了，所以应该用 308 更合适？

@Anonono #11 不太记得当时怎么想的了，貌似是看了那个 stack overflow 的回答就直接复制过来了。。。
看了下那个回答的修改记录，最开始是没有 301 =307 这一段的，测试了下这样默认就是 302 。
然后底下有个人说加上 301 =307 防止请求方法发生改变（ 301 和 302 的标准规定请求方法不变，但是部分浏览器实现会在重定向后变成 GET ）。
但是实际上测试了下，只写 =307 或者 =308 就行。
前面的 301 只在 upstream 服务返回了 301 状态码的情况下生效，用于改写为 307 （按理应该改写成 308🤔）保留请求方法。