我应该提示一下使用托管代码写密码算法是不宜在生产中使用的，因为无法精准控制密钥何时从内存中删除（垃圾回收算法可能会随意搬动和复制内存数据，所以仅仅是清空或覆写数组是无意义的）。

当然是删除传入 del=1 合理，否则只要有两个客户端并发保存数据就很容易发生踩踏事件。

两个客户端可能只是开了另一个窗口，或者离开窗口很久之后忘记，重新打开，并在一年之后回到原来的窗口。

没看懂整个工作流程，你是在 Visual Studio Code 里面打开了网络共享文件夹，还是用了 VSC 的某种远程工程，还是在本机通过远程桌面等协议操作运行在远程计算机上、打开远程计算机上的本地文件夹的 VSC ，还是怎么样之类的？

第一段“都是在远程服务器上工作”听来是远程桌面到服务器（ VSC 在远程计算机上运行）的意思，但是后面“发现电脑休眠了”好像又是说 VSC 在本地计算机上运行（因为我假设是办公室的客户机休眠，而不是服务器休眠）。

什么叫“打开文件系统”？文件系统是操作系统提供的抽象，没有打开关闭之说。

第二点感觉不是“洁癖”可以描述的，看起来是比较严重的“强迫症”。如果非常严重应该看医生，网上求医问药效果不好。

取决于你的劳动合同，你可能没有这种权利。

@keithwhisper #19 建议不要重新定义 open source ，开源并不代表应该、需要接受社区的意见、帮助。你所引用的评论也混淆了开源准确定义和“包容开放社区”的想象。

读了一下文档，看起来 drop_caches 只能清除文件系统里没有写过的缓存，sync 的作用是刷新所有文件，此外楼主的命令的影响范围是整个系统，而不是自己的进程，这样做几乎永远是错误的。

@codehz #5 可能楼主需要写很多内容后一起刷新？

关键词是 linux flush cpu cache

自卖自夸一下但是可能不适用于微信/QQ /t/638439

@yankebupt #16 经典计算机的对立面是量子计算机，这样说是因为利用量子计算可以让（发送给客户端的）程序只能（被客户端自行）运行一次，但经典计算机没有这种可能。

#18
>把明文的 Hash 也发过去让他自行验证。
我的解读是客户端会收到正确答案的 hash ，这样的话客户端可以自己尝试所有可能答案，计算它的 hash ，直到匹配为止，然后再把答案发给服务端。

>服务端只需算出他生成的那些张的 Hash ，而客户端需要枚举所有。而且等客户端枚举完，服务端可能以及换了一批 Hash 组合了
或者如果不在意服务端亲自 Hash 一下的话，可以每次给客户端随机的Ｈａｓｈ组合算法用于验证……
比如
md5(sha1(salt(sha1(salt(md5())))))
salt(sha1(md5(sha1(salt(md5())))))

不太理解，客户端要想自己比对，当然需要知道如何计算 hash ，换用不同的算法没有意义。

In any case, 这个方案不好。此外，从攻防、补丁的角度思考效率也不高，应该从形式化和证明的角度思考。

@yankebupt #1 （经典计算机的）客户端不能自己验证，通常来说验证码的长度不足以阻挡离线枚举。

如果是注册验证，一个简单的避免重放的思路是让验证码和注册信息绑定。当然我没有仔细想过这样做的问题，标准解决方案才是正道。

@Jirajine #28 很明显是为了避免《微软公司升级系统故意让某公司软件不能运行，我们要抵制微软、反垄断》这类文章。有些开发者的电脑上路径没有空格，且很多开发者有自己机器上测试的坏习惯——正确的测试方法是在一台全新安装的 Windows 机器上测试（可以检查出很多“只有开发环境下才能运行”的 bug ）。

另外，Windows NT 4.0 的时候用户资料默认位置是 C:\WINNT\Profiles\用户名，而 Windows XP 里面默认位置是 C:\Documents and Settings\用户名，所以即使一开始在全新安装的 Windows 上测试过程序也不代表就会在以后的默认安装上成功——当然那个程序已开始没处理过空格就是错的。

我也不喜欢这种设计，因为某些程序自始至终就不是正确的，但这类程序就是很多，从 DOS 和 Unix 来的程序经常这样。

扩展阅读：搜索 8.3 names site:devblogs.microsoft.com/oldnewthing 以及把 8.3 改成 short 搜索。

@Ocean810975 #18 应该也不是很早期，因为 8.3 格式的名字里不能有空格。

@ulosggs #20 这个理解比较片面。首先，分区的文件系统可以选择不支持短文件名，也可以通过注册表关闭短文件名的生成。如果一个名字已经符合 8.3 的要求，就只会转换为大写作为短文件名。另外短文件名和创建顺序有关，第一个以 PROGRA 开头的无扩展名长文件名在 Windows 的常见实现里会得到 PROGRA~1 这个短文件名，第二个则是 PROGRA~2 ，更更多的情况还有更复杂的命名方法（ Windows 上的常见实现大概会有四位 hex 之类的），还有在短文件名已经生成后建立长文件名等于已经存在的短文件名的情况。PROGRA~1 只能表示某个特定的文件，不能表示所有以 Progra 开头的长文件名文件。

最后，使用 PROGRA~1 表示 Program Files 的程序不应该被理解为“不想处理空格”，这实在是太美化它们了，更好的理解是

自从 Windows 3.3 以来就没更新过的程序，或者
写得很糟糕的程序，或者
忘了声明自己是 Windows 95 之后开发的程序

在现代文件系统里存储短文件名只是为了兼容上个世纪的程序，不是允许新程序逃避现实。

@XiLingHost #3 Program 的 8.3 文件名是 PROGRAM ，会出问题是因为很多 Windows 软件没有正确处理空格，在调用 API 的时候把命令行设置为

C:\Program Files\abc\def.exe xyz

按照正统理解，这是在打开 C:\Program 并传入参数 Files\abc\def.exe 和 xyz ，但是现实世界里意思大概是打开 C:\Program Files\abc\def.exe 并传入参数 xyz 。

为了兼容这种情况，Windows 会尝试修复首个命令没有被 " 包围的命令行，方法是从左到右尝试寻找最短的以空白分开的串，满足这个串代表的路径存在着文件，然后把需要打开的文件理解为这个串，剩下的理解为传入的参数。

读者习题：以上面的坏例子，解释为什么存在着 C:\Program 文件可能会让一些程序坏掉。

此处应该记住的是永远要正确转义命令行，文件名可以包含空格。

这个想法过去已经被尝试过无数次了，比如随便一搜 https://www.reddit.com/r/chrome/comments/3xrrad/a_comment_extension_allowing_free_speech_on_all/

或许中心化的性质是这类服务的弱点之一，比较 WWW 的做法是在自己的网站上链接要评论的东西并写评论。

普通打印机是对不准的，打印的版式容差能力需要很强（比如如果是表格的话，最好内间距大一些，而且第二次打印的时候不要重新打印框线）。

另外网页无法控制打印的效果，采用相同浏览器、相同版本、相同打印设置才能续打，而且如果一开始已经打印多页，最好不要自作聪明删除多余的数据，因为网页不知道浏览器分页的位置。

“给编程初学者出什么题让他不能直接从 GPT 获得答案？”

这个问题是 GPT 无法正确回答的（对角线论证）。

@itskingname #20 问题：a[b[c]d[e] 的提取结果是什么？

或许可能说不定微信根本没有这个功能。（ Windows 上的微信很多 UI 都是自己搞的一套不太行的版本。）

楼主应该巩固一下现代汉语，0 楼的内容读起来很不连贯。

另外我觉得“掌握”“懂”是很虚的概念，即使考虑这个概念，“掌握”“懂”也可以分不同的等级。就我个人经验来说，“懂”和“可以用各种语言实现”数据结构和算法，可以是完全不相关的两码事儿，前者是计算机科学问题，后者是计算机技术/工程问题。

我小时候并不“理解”快速排序和并查集，但是了解任何语言的基础知识之后都可以很容易写出快速排序和并查集。我写快速排序至少两年之后才理解快速排序，而且我至今也不能算是理解了并查集——没有内化它的复杂度证明就不算是理解。