同志，这和防 MITM 不沾边。如果你乐意的话，可以给 DOM 上 HMAC, 然后再检查浏览器 DOM 的 HMAC 是否匹配。但这样最终是逃不过浏览器内的各种魔改的：我可以屏蔽你的检查脚本；我可以 hook 进你的检查脚本，在你检查完毕之后再修改页面；我甚至可以通过透明代理直接将整个页面内容拦截重写，只保留我需要的那部分；如果有流量加密，那我就找到渲染广告的部分，再屏蔽这一块，广告虽然被请求也不会被渲染——就算你的框架有混淆，我也可以通过 DOM 修改断点找到关键部分；如果说再带上全量 Canvas 渲染，性能会变得特别成问题，以及届时你会发现自己在用 JS 实现一个浏览器内核，以及你得想办法让搜索引擎能读懂这一堆东西。Good luck, have fun.

防止页面内容被篡改的唯一方式是：不可能，除非用户主动参与校验。或者放弃 B/S 转战 C/S, 后者你甚至可以自己再在 TLS 之上加一个非对称加密，这样就算通过透明代理也难以过滤任何请求。但这么折腾下来，值得么？屏蔽广告的人不是你的广告受众；不屏蔽广告的人也不会对你的广告产生兴趣；页面上堆了一堆的无关内容只能导致 PV 进一步下降；性能损失带来的还包括搜索引擎降权。

[KDE Connect]( https://kdeconnect.kde.org/download.html) 可以让手机和电脑之间同步通知，可以熄屏使用。需要在同一个局域网下（至少两台设备可以直接相互）。

如果用零宽空格的话，有些站点会把这些字符过滤掉，就没法正常解码了。

@skydiver #18 同时，如果你真的尝试去找那本杂志，你会发现这本杂志并不存在。1993 年 1 月的 PC Professional, 任何语言版本都没有这篇文章；更没有名叫 Lisa Birgit Holst 的主编写这篇文章。几乎可以肯定，这是 Snpoes 捏造的一篇文章——要用谣言打败谣言！（不）

注意循环报道。

当然是读 D Flat 或者 C Pound （

如果是科班，就不要挑语言了。穿透框架和语法看算法思想是核心要义。
当你钻研到足够深入的时候，你需要思考的就是数学问题；具体选择哪个语言实现就是个人喜好了。
<del>(Haskell for the win!)</del>

我在大二的时候对就业情况也挺焦虑的，但后来真等到要就业了发现其实也就是那么一回事。
基本功足够扎实的话，虽然进大厂不靠谱，但至少保证自己不饿死还是可以的（）。

如果你真的觉得焦虑或者没有方向的话，有两个方案：刷题或者做一些 toy.
在这个过程中你会快速地积累实践经验、踩一些实际开发过程中常见的坑。
但应注意：最好不要靠背套路刷题。如果你的目标不是在短时间内开始打 ACM 的话，务必不要背套路。
去自行探索。花费的时间肯定会很长，过程肯定会很痛苦，但希望你能靠对计算机科学的兴趣撑过这段时间。

4 年（实际上是差不多 3 年）的时光可能没法让你追赶上从小学就开始编程的人，但足够你超越荒废大学时光的其他人。

祝好！

顺便说一句不相干的，一逗到底可不是好的写作习惯。（虽然比一些通篇用感叹号当逗号和句号的人好一些，但看起来还是好累...）

@xy90321 在 NodeJS 15.8.0 的 REPL 里测试，确实输出 99. Firefox 85 下测试结果为 10.

我原以为 JS 里没有这种未定义行为 /依赖于解释器实现的行为，今天是长见识了。

@Kininaru 不过这个就需要缩写确实可以按照英语单词来拼读。"NA" 和 "SA" 都是可以出现在英语里的音节，而且一般不会有音节拆分上的歧义，所以可以读 /nasa/. IMEI 的话，音节拆分容易出问题：IM-EI /im'ei/ 或者 I-MEI /i.mei/ /i'mei/ /'imei/ 都是可以选择的拆分。但 `im` 又是一个常见的前缀，选择第二种拆分有一种难以名状的刻意感。

以及，在英语里，以 `im` 开头的单词之后大多跟一个辅音 (im-p-, im-b-, im-m-)，但这里跟了一个元音，就让人感觉怪怪的，不像是英语里能出现的单词。这种冲突提示了这个单词应该逐字念出，而不是一个单词。

就像 HDMI 一样，/h/ 开头的单词后大多跟一个元音，但是 d 和元音不沾边；选择不发 /h/ 直接发 /d/, 但 /d/ 开头的音后面也需要一个元音而 m 和元音也不沾边；所以就直接念 H-D-M-I. 尽管 `mi` 是一个可以出现在英语中的音节，但是前面已经选择念字母了，后面就应该保持一致，而不是念 H-D-米 或者`喝地米`。

以及，各位想到怎么念 XKCD 了么？:P

Language is messy and it's keep evolving.

You don't. Just make good things. It's NOT a test and you DON'T have to collect stars to make a living.

你要是真喜欢看数字往上涨的话，可以玩一些放置类游戏消遣一下。

如果不能预知任何信息，只知道这会是一个用户输入，那么这个需求是完全不靠谱的...

不过因为是解析为 JSON, 那么按道理应该是可以使用 `SafeConstructor` 来解析成 POJO.

或者，自己写一个 ClassLoader 提供给 SnakeYaml, 拦截掉你认为危险的 Class 就可以了。

@zxc1234 #22 是的，可以认为如果 /0 没有捕获也会导致 crash.

至于平时项目，真正能见到的最常见的 crash 算是 NullPointerException, IndexOutOfBoundsError 其次是 OutOfMemoryError. 不过如果平常只是写写 CRUD, 那么在各种框架和静态代码分析的加持下就都很难见到（当然，一旦见到就说明出大事了）。JNI 库的话自己写不经意的话就容易出 segfault. JVM 的非法内存访问就更罕见了。

@zxc1234 #20 Java 里面除以 0 不是 crash 是 exception: java.lang.ArithmeticException.

不过硬要说的话，除非是内部错误（比如 JNI 库中的或者 JVM 本身的非法内存访问），否则类似与内存耗尽这样的应该导致 crash 的异常也是可以被 catch 的。不过一般情况下不会尝试 catch 这类异常。

其实 crash 更像是一种结果而不是一个过程。JVM 进程异常退出了，我们就认为发生了 crash, 哪怕这只是因为一个没有 catch 到的异常。

@zxc1234 #17 crash 一般是无法被 catch 的，它和 exception 不同。crash 是发生严重的、不可恢复的错误才会出现的。

仇恨和愤怒是在网络上传播最快的、影响最广的情绪。看来帖主深喑此道。

@ipwx #2 其实 Linux 桌面（无论哪个发行版）都是非常难以做到开箱即用的。除非愿意像 Chromebook 那样铲掉「不友好」的部分，不然总归是会出现门槛的。

#23 Linux 桌面半死不活某种意义上是好事。因为用的人越多，你就需要去为人做支持，而不仅仅是为技术做支持。诚然，Linux 中的很多设计也是人为原因，不过毕竟众口难调啊。Windows 算是为人做支持的集大成者了，Linux 想要追上 Windows 的为所有人提供支持几乎是不现实的。

#25 我从 2016 年以来为身边除了平板以外的电脑都装上了 Arch. 不过我所有安装过的 Arch 一直都正常运行且正常工作，而且每台机器的配置都不尽相同。滚挂是完全没有发生过的事情。我很好奇这算是我运气比较好呢，还是我捯饬得不够深？抑或是上古配置的支持比较完善一些？

@hakono #79 类推可是容易出问题的哦。

卡的话当然是要跑 profiler 了，光在这里猜原因肯定是猜不到的。CPU 内存和闪存都可能是性能瓶颈