@GopherDaily #14 错误的方式可以有很多，没有必然理由认为你的错误答案程度更轻，建议不要和别人玩“揣摩出题人意思”的游戏。

#15 你可能没有理解我的意思。

>我们在下述例子中看到, i 和 v 的内存地址始终未曾改变: ...
>另外 i 和 v 的地址未曾改变不能证明任何事情，即使每次迭代的变量是新的，编译器也可以证明复用旧的内存位置没问题，于是优化之后会看到相同的地址。

引述第一段内容，阅读后揣摩得出：这段话是想要通过地址不改变 (A) 证明迭代变量每次都是同一个 (B)，即论证 A => B ，并观察到 A ，因此推出 B 。
引述第二段内容，意思是 A => B 的论证不恰当，并不是说 A => B 这个命题本身不真。

换言之，A 对论证 B 是无意义的，论证 B 的惟一方式是阅读 Go 的定义。

这段代码不能推断任何事情——都不知道 scopes 、x 、complete 、close 是什么！假设 scopes.stream() 是 sensible 的。

如果 scopes 是空集，则 anyMatch 当然永远是 false 。
如果 scopes 不是空集，那么 getProcessStatus() 可能有副作用，连续调用两次不一定返回相同的数值。
我们也不知道 complete 和 close 是不是相等。

如果假设 getProcessStatus() 无副作用，且 complete 和 close 不相等，那么 b1 的结果等于 scopes 是否是空，这依然是非平凡的，除非上文里编译器可以推断 scopes 非空。

培养逻辑直觉的第一步是放弃错误的直觉（也就是所谓的“想当然”）。

随便看了一下文档，正确答案不是“乱序输出三个数字”，而是“乱序输出三个数字或者程序在不知道什么时候崩溃”。

https://go.dev/ref/mem

> While programmers should write Go programs without data races, there are limitations to what a Go implementation can do in response to a data race. An implementation may always react to a data race by reporting the race and terminating the program. Otherwise, each read of a single-word-sized or sub-word-sized memory location must observe a value actually written to that location (perhaps by a concurrent executing goroutine) and not yet overwritten.

另外 i 和 v 的地址未曾改变不能证明任何事情，即使每次迭代的变量是新的，编译器也可以证明复用旧的内存位置没问题，于是优化之后会看到相同的地址。

是因为默认的字体兜底顺序先考虑日文字体。

解决方法是在数据中（比如 HTML lang 或者 font-family ）指定正确的语言、字体兜底，以及使用正确编程的程序。

目测 mt_rand(10000000, 99999999) 的输出一定以 1 开始，那自然不是均匀随机的 8 位纯数字序列号（当然 MT 本身就不够随机，但这是另一码事儿了），毕竟均匀随机的 8 位纯数字序列号以 1/10 的概率以 0 开始。

对这个分布套上 str_shuffle 是会“变得更随机”（增加分布的熵）的，但 str_shuffle 之后得到的依然不是八位纯数字序列号，因为它不可能是 00000000 ，而真正随机的以 10^(-8) 的概率出现 00000000 。

如楼上 @maggch97 所说，这个数据范围出现碰撞的概率不小。最简单的做法是：预先生成好 0 到 99999999 的一个置换（打乱一个 0 到 99999999 的列表，并存下来），然后每次需要的时候取用。

@summerLast #4 我的意思是，想要听到屏幕上显示的东西，在 macOS 下只要打开 VoiceOver 就行了。

@ysc3839 #19 如果是 Windows 95 以前，那么最小化的窗口就在原地，从 Windows 95 以来的非 NT 系统采用的是 (3000, 3000)，然后 NT 系列是 (-32000, -32000)。

回到楼主的提问，我记得 Windows 7 的时代是可以假装有外接显示器的。但如果单纯想让窗口在屏幕外，那任意版本的 Windows 好像都可以。

回到歪楼的内容，Windows 10 Mobile 也支持外接显示器显示不同内容。

是“小而美”（反语），这个功能属于读屏器的生态位，没必要在 RSS 订阅与展示工具里再写一次，除非这个阅读的语音是人类录制而不是计算机生成的。

你引用的 CSDN 文章已经说了要加上 256 是错误的。

问 ChatGPT 得到的答案不可靠，尤其是带着具体细节提问的时候，因为 ChatGPT 一容易编造内容，二容易“讨好”用户，用户尝试错误地更正它的回复的时候，它很容易“好好先生”地同意用户的说法——如果你问 ChatGPT 为什么要做 XYZ ，那么它很可能不会考虑这是否是伪命题（即实际上可能不需要做 XYZ ）。

企业邮箱就是设计给企业用的邮箱，一般有很多企业会用到的功能，比如：多用户，权限代理（秘书可以读取老板的邮件来协助处理），管理员可以重置任意用户的密码，设置数据保留策略（彻底删除的邮件实际上必须过一段时间才真正彻底删除），电子文书提出（所谓 eDiscovery ）等。绑定自定义域名也是企业邮箱的常见功能之一。

企业邮箱的数据所有者通常是客户企业（一个法人），而不是客户企业的员工（通常使用邮箱的那个自然人），通常对于数据的 safety 可以通过合同约束服务提供方。
个人邮箱的数据所有者通常是客户，对于数据的 safety ，服务提供方通常是无责任的（格式条款）。

提前解释：safety 是指数据不丢失的性质，security 是指数据不被别人查看的性质。

@geelaw #3 哦，不必这么麻烦了……可以用 IExplorerCommand 接口，用 GetState 可以决定是否显示。

如果你不需要“在没有 .heic 时不显示”这个效果，那么可以用 IDropTarget 。

这两种方法都要求写代码，而不仅仅是修改注册表。

可能是 IContextMenu 系列接口

@geelaw #26 Alas 刚发现之前有人说过了。

@hippoboy #18 重音作用在元音上；一个音节可以是 V 、CV 、VC 、CVC ，其中 C 表示辅音（群），V 表示元音；重音符号写在音节开头。

present 有两个音节，第一个是 pre 第二个是 zənt ，因此 e 变重的时候重音符号在 p 前，不代表 p 本身加重。这里 pr 、nt 就是辅音群的例子，由多个辅音组成。

因为直接写 0 不会导致 nextIndex 增加到 1 ？

是 feature ，如果 A 和 B 是“认识的人”那么会显示通讯录里的名字。不过 AirDrop 有其他不安全的地方，比如当 A 和 B 不认识的时候，B 依然可以知道 A 的手机号码，这是熟知的，见 https://privatedrop.github.io/

@geelaw #30 Ugh, 应该是 ceiling(k^n/(m-n+1)).

@geelaw #13
@acr0ss #29

de Bruijn 序列 B(k, n) 的定义是 { 0, 1, ..., k-1 } 的有限序列 X = X[1]X[2] ... X[L] 使 L >= n 且所有 { 0, 1, ..., k-1 }^n 的元素都在 X' = X[1] X[2] ... X[L] X[1] X[2] ... X[n-1] 恰好作为子串出现一次。已经知道 B(k, n) 的长度是 L = k^n ，注意 X ' 长度为 n 的子串恰好有 L = k^n 个，且 { 0, 1, ..., k-1 }^n 恰好就有 k^n 个元素。

在你的情况里 k=10, n=6 ，但 de Bruijn 序列并不是你直接要的答案，不过已经非常接近了。

你希望寻找一系列长度是 12 的串 Y(1), ..., Y(z) 使得诸 Y(i) 的所有长度为 6 的子串覆盖了 { 0, ..., 9 }^6 ，很明显 z >= ceiling(10^6/7) = 142858 ，而取

Y(i) = X'[7(i-1)+1] ... X[7(i-1)+12]
1 <= i <= 142857
Y(142858) = X'[7(142858-1)+1 = 10^6] ... X'[10^6+(10-1)] 0 0

则诸 Y(i) 的所有长度为 6 的子串当然就包括了 X' 所有长度为 6 的子串，后者就是所有长度为 6 的串。这说明需要的 z 可以是 142858 。

暂且称上面长度为 12 的串是“窗口”。类似地，可以算出密码字符有 k 个，密码长度是 n ，窗口长度是 m 的时候需要的最小的窗口数就是 ceiling(k^n/m)。

计算最小窗口数和计算这一系列窗口是两回事儿，不过后者也不难，de Bruijn 序列有算法可以生成，再练习一下使用搜索引擎的能力就好。