首先，没有绝对的安全。如果真到了可以到你服务器上进行任意代码执行了，那基本上对你的密码是啥也就没啥兴趣了。都能直接进到你家翻箱倒柜了，也就没有必要知道你家防盗门上的密码了。
安全防护通常是很多层，对密码的保护只是其中一层。
代码是很多人都可以访问到的，比如公司里的程序员，几乎人手一份代码，代码泄漏的风险本身就很高。而密码不放在代码里，那么即便是你泄漏了代码，在不考虑其他漏洞的情况下，生产数据库还是安全的。
当然，即便是保护了密码的安全，生产数据库通常也都是网络隔离不能公网访问的，这是另一道安全防线。但也不能说既然不能公网访问，那就不设置密码了吧？

@gransh Chrome 浏览器，右上角设置图标旁边可以添加 profile ，相互之间数据隔离，不同 profile 可以换个不同的主题色，也是比较清晰的不容易搞混。
临时测试用隐身模式，隐身模式是同一个 profile 下的临时环境，插件是共享的。也可以用访客模式，访客模式会把所有插件都禁用，相当于一个临时的 profile 。

+1 也遇到了，建行的 VISA 双标，一直续费正常的，这个月突然断了

人类：随便选一个
机器人：sleep(2e3 + random() * 5e3); select(floor(random() * 9));

@jinqzzz sort 有个比较特殊的点是，它必须一次性把所有内容都读入才能开始输出，因为有可能最后一行的内容被排序到最前面。在输出之前，内容都是要读到内存里的，处理大文件要足够的内存。
所以可以用一些方法来延迟 tee 创建输出流的时间，确保 sort 已经读取所有内容。
如果是 cat xxx | tee xxx 这样的，cat 是支持流式处理的，也就是读多少输出多少，读取的内容可能比内存都要大，这种情况 sort 命令都肯定要失败的。这种就不建议延迟 tee 了，还是换个文件名来写，确保读取写入全部完成之后再做文件替换是比较稳妥的。

@DeWjjj #31 试想一下，apt install 某个软件，之前是直接装上这个软件。现在是只提供 docker 镜像，apt install 是先给你装个 docker ，然后自动帮你跑一个 docker pull ，创建的 bin 是个 docker run 的脚本，你再想想能不能接受了。
snap 和 docker 都有存在的价值，可以接受一个软件同时提供 snap 和 docker 的安装方式，但是不接受的是你改变原本工作正常的 apt 安装的逻辑。
想用或者需要用 snap 的人自然知道怎么装 snap 版本。

@NaiveSimpleYoung #5 走标准的 DNS over HTTPS 或者 DNS over TLS 的话，各种语言应该都有库，现在大部分公共 DNS 服务也都提供了 DoH/DoT 的解析。关键词就是 DoH 或者 DoT ，网上搜一下就有了，不用知道底层原理。
或者自己实现私有的 httpdns 的话，估计就得服务端参与支持了，得自己搞，不过其实难度也不大。

我觉得上一个示例和这一个示例逻辑上都没问题。
上一个示例是改 increment ，计时器应当每秒更新不受 increment 的影响。
而当前这一道题是改 delay ，那么既然 delay 变了，按道理计时器就应该以新的 delay 值来更新，因此重置计时器没有问题。
而如果不重置定时器的话，delay 一直在变化，那么你究竟以什么时间间隔来更新数据呢？

@fpk5 #54 刚试了，是可以的

感觉 git 本身就是这么设计的啊，分支就是文件夹。
分支分为本地分支和远程分支，本地分支在 .git/refs/heads 下，以斜杠为目录存储，比如 main 、feat/feat1 ；远程分支在 .git/refs/remotes 下，以远程名与分支名用斜杠分隔，按目录来存，比如 origin/main 、upstream/feat/feat1 。
远程名里也是可以包含斜杠的，所以你的上游不仅可以叫 origin 、upstream ，也可以叫 upstream/cn 、upstream/us 。
所以远程分支也可以是 upstream/cn/feat/feat1 ，其中 upstream/cn 是远程名，feat/feat1 是分支名。

不过，这个确实可能会存在冲突的问题，比如你本地一个分支名就可以叫做 origin/main ，这样就会和 remotes/origin/main 冲突，在 git checkout origin/main 的时候就会收到警告：warning: refname 'origin/main' is ambiguous.。这时候实际上切换到的是本地的分支，要切换到远程分支进入 detached HEAD 状态，需要指定 git checkout remotes/origin/main 。
而如果本地有个分支叫做 remotes/origin/main 的话，又会冲突，那要切到远程分支就要指定 refs/remotes/origin/main 。
如果本地又有了 refs/remotes/origin/main 分支了，emmmm ，应该就没办法直接用分支名来切换了。

@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 脚本路径，然后快捷方式右键属性能设置快捷键