子组件获取祖先组件的数据，这个逻辑没有问题，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🤔）保留请求方法。

@jinliming2 hello.getBytes 的时候得到了 GBK 编码的 byte[]

content-type 里指定的编码，是浏览器解码的。
你的问题是 hello.getBytes 的时候得到了 GBK 编码的字符串，但是 new String 又给还原成了 UTF-16 ，最终把还原的 String 丢给 Result ，浏览器拿到的数据是 UTF-8 编码的，但是 content-type 指定用 GBK 来解，就乱码了哇。
Java 不熟，你可能需要看看那个 Result.success 最终能不能用 bytes 来返回，直接 getBytes 之后丢给浏览器