你这样写其实访问的是 globalThis.test ，而你期望的 test 在 createDomTree() 里是在 this 上

看 https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols 就知道，git 协议是为「公开的大型项目」而设计的，它不需要 HTTP 协议的各种限制，也不需要 SSH 的加密和认证机制，git 协议和 SSH 都是建立在同一层的。简单说 git 协议就是明文传输的，可以被中间人攻击

@waising 不好，without timezone 的情况下需要保证客户端输入的是 UTC ，否则容易出错。显然还是让 dbms 自己处理时区更能减少问题

其实 WSL 的前身就是为了让 Windows Phone 可以兼容运行 Android App

@bthulu IList<T> 的 T 同时出现在参数和返回值里，它就是不变的

@bthulu 具体类型是不变的，所以无法赋值。这个例子下必须使用 IReadOnlyList<Animal>

@eason1874 很多口嗨都是些没进过社会的学生群体

已知 RA3 的 AI 是可以学习玩家的出兵方式和使用的战术

思维不要停留在 Windows XP 时代，这年头只要是个正常的操作系统都会尽量让内存不要空闲太多

印象中 Windows 通用的那套顶多也就 macOS 的 Options 修饰键的，最多是以词为单位

你说的是 Ctrl+BackSpace 吧

作为 CDN 就不太现实，因为命中率太低了。不过网络视频 /直播应用使用 P2P 的做法已经存在很久了

体验上的实质区别得在新的硬件上才体现得比较明显，因为 Android 的 64 位迁移已经是要靠硬件来强制推动，之前靠软件层面的推动都不怎么有效

去年的一些三丛集 ARMv9 架构 CPU 只有大核保留兼容 32 位的指令集，这意味着 32 位的应用全程只能运行在大核上，利用不了超大核的性能以及小核的低功耗，相比 64 位的应用会显得性能不佳且耗电
而 ARM 最新发布的公版 CPU 其大核也砍掉了 32 位指令集的兼容，这种情况下的区别就更明显了——32 位应用根本无法运行

说得好像 .Net 开发就不能用 mac 似的

会用，因为平时习惯用正则，相对地写起来更舒服。而 LIKE 匹配和正则匹配本质上都是个状态机，相同的匹配逻辑下一般不存在什么性能差异

基本上认为是不支持的

最早的 jsonpath 实现（ https://goessner.net/articles/JsonPath/index.html#e4 ）的作者有提到建议对过滤后的结果再做一次 jsonpath 查询或者使用语言的数组操作。而某个 jsonpath 实现的库对该需求也是个疑难杂症（ https://github.com/json-path/JsonPath/issues/272 ）。SQL 标准使用的 jsonpath 也没有该需求的解决方案

看是否有经常录入大量文本的需求

HTTPS 防的是传输过程中不会被监听，但是不防中间人攻击

假如中间人能获取到发送者的公钥，那中间人就能解密并篡改请求，所以要用额外的私钥签名防止内容被篡改；但只有签名也不行，因为中间人可以选择不解密原文重发，所以还要加上时间戳并参与签名防止重放攻击

@beginor 16" M1 Pro 表示不热的前提是手动增加风扇转速