@cmdOptionKana @Hconk @Leviathann
不是发代码，是发单纯的发文字，而且是现写的。类似于「站内没吵完，站外接着吵」。

「死机、蓝屏」用了 macOS 肯定会好，为什么？因为 macOS 需要适配的硬件很少，只有那几个在卖的，自然就没有那么多驱动兼容性问题。更贵的 Win 本也不会改变这个问题。但我觉得，这也不是 Win 的缺点，应该要问你的硬件厂商。

然后，.NET 开发肯定是不能用 macOS 的：
一，是这不清真，有大把别的语言可以选，为什么偏要恶心自己；
二，.NET 开发肯定不止 .NET Core ，然而只有它是跨平台的。

最后，能不能无脑上 macOS ，我的答案是不能。从你的答案来看，还没有为 Win 的字符集、四代同堂、字符渲染、DPI 缩放、装个软件动不动就要重启、pwsh 、干啥都要 WSL 感到厌倦；还没有在 Linux 上折腾 QQ / WeChat / 腾讯会议 等深恶痛绝但不得不用的腾讯系软件；理由还不够充分……

@kkocdko 个人觉得，客户端渲染好一点，因为如果要支持 dark mode 就需要构建时渲染两套。不然就是套上白底，会很难看

Hexo 慢是硬伤，以前博客就是用的 Hexo ，写了十几篇，每次 build 印象里就是非常卡…… 这也是我迁移 Hugo 的主要动机。另外就是，每次改主题都要魔改 node_modules ，太不清真了 = =。

hash + 取模。比如 id * 114514 + (end * 5147 - start * 305) + price * 191981 + count * 47297 再 + 100 再 % 721 。跑了点随机数据出来 max 820 min 100 avg 460. 并且数据少的话，波动很大。

@guoqiao Python 一堆下划线也好意思说？…… 看到一堆 __init__ 就想吐，更何况连基本的编译时限制都没有。严重怀疑你下一步是不是要说：「什么类型检查、什么可访问性修饰符，全部都能 Hook ，都不存在，都是程序员的规定而已」。

脚本语言不需要是因为不需要太考虑兼容性和类型…… 但，如果你写的是库，就让别人天天访问 private ，任意传空值？

天天「确实需要」的时候，难怪 Python 库总是动不动在 Minor Version 改 API 。

因为小错误酿成大错的例子并不罕见，之前 B 站因为一小段 Lua 造成整个服务器瘫痪，就说明了无类型检查的弊端。

Java 因为设计问题，空值处理很垃圾；但 setter / getter 很好地补全了这一问题。这是 setter 和 getter 有用的又一例证。不过……看你的观点，可能会说「既然非空类型有利于预防程序错误，那我们要求所有人都必须写 type hint ，不写的不过面试，好不好啊？」

更搞笑的是，还扯上移民了……

问题在于，你可以更改 get 和 set 的实现，但不能更改字段的实现。

并且更重要的一点，由于 Java 没有不可空类型。你可以在 get 时检查空值。

这种约定为其他许多 JVM 语言提供了坚固的基石。Kotlin 在 Java 世界遵循 getter 和 setter 规范。而在 Kotlin 自身，它将 setter 和 getter 视作 property 。Kotlin 的空安全是极为重要的一点。对于 Kotlin 自身代码，可以在编译时检查，而对于 Java 调用或反射调用，则需要运行时检查，因此必须有一个 getter 。

getter 、setter 绝不是教条主义，只是缺乏一个语言层面的语法糖。

建议 Hugo 。

1. 感觉不会有完全满足的… 0.2 秒太极限了。按我自己的测试，最接近的可能是 Rust 写的 mdBook ，100 个条目只用 1.5 秒。其次是 hugo ，93 个条目用了 3.7 秒。而 Hexo 简直惨不忍睹。

至于 100 KB 限制，这也不太可能，因为 MathJax 起步 MiB 级，KaTex 起步 300 KB ，和你的需求 2 冲突。

2. hugo 完全满足。

3. hugo 主题挺多的，应该能有符合这种风格的

4. 正是

还是挺难的。内部项目也是要前后端配合的。

但是之前扒 B 站 API ，发现好多接口返回 camelCase 和 snake_case 的同样字段，这种就比较过分了。

（用 Protobuf 就没有这种问题了，因为不用传字段名）

我又来宣传 gupa 了：
> where gupa
gupav: aliased to git pull --rebase --autostash

从远程这样拉的话，能够避免额外的 merge 。--autostash 选项相当于 在 git pull --rebase 之前 git stash ，之后 git pop 。

建议了解一下 JDK 9 引入的模块化，Java 对访问 JDK 内部实现的限制越来越严格了，尽量避免反射 Java 内部类，以及使用 sun 开头的包。

要说还有什么坑，用了 finalize 的话，JDK 17 已经标记为 forRemoval 了…

具体不清楚，但印象里 AC-3 比 AAC 更坑。

如果是开发音视频相关的，为啥不 Opus 呢？

我也被这玩意困扰过……一堆参数隐式传，文档又不写，还要自己看源码。前端方便了，后端对接 sb 了一样。

@nothingistrue 不是默认繁体，是谷歌搜出来是繁体。path 是 zh-hans ，又想要简体，维基也很为难。自己把 path 改成 wiki 开个匿名打开就知道了……

另外不是「小语种」…… 自行搜索 w3 文章 Language tags in HTML and XML 。

要解决最好的办法就是登录。登录之后可以选语言变体，可以选主题。两个问题同时解决。

> where gupav
gupav: aliased to git pull --rebase --autostash -v

1. 关掉「系统设置-键盘-输入法-使用“中 /英”键切换“ABC”输入模式」
2. 这种问题恐怕用 Rime 是最好的…… 因为有完备 Lua 脚本支持。如果想用系统输入法达成，可以试试 Automator 和 Alfred 之类，调 Shell 脚本回传日期。
3. 无解。设备间词库不互通。自定义短语倒是互通的…… 然而应该不适合加词库的场景，很麻烦。

-

如果想要商业支持的完备输入法，可以试试落格输入法。应该能解决你说的词库问题。

另外如果是全拼用户，可以试试双拼。（因为落格、Rime 的卖点里，双拼占很大一部分… 当然 macOS 现在也自带了。）

系统输入法的可配置性为 0 。对我来说，最大的问题是 CPU 占用一高，就非常卡，再搭配上腾讯系软件的卡顿，简直酸爽。用 Rime 则没有这个问题。

这个应该问 Windows ，忍受编码问题是 Win 用户的基本功。😢

@ysw #1 这不是到 2022 年了，适配还这么烂的理由…… Linux macOS 都挺正常的。

1. Go 语言性能高吹的成分居多，你列的 Gin 在 TechemPower 的排名里面排第 63 位，是第一名性能的 23%。Fiber 框架性能在 Go 里最高，然而 Star 不如 Gin 。整个 Go 的平均性能可能和 Java 差不了多少... 说 Star 数多少多少真心没啥意义…… Go 这么火，你还是要搞清楚一点不是他语言多厉害，纯纯的就是微服务撑起来的。

2. Go 还可维护。动不动就是 codegen ，类型系统不是简约，是简陋。天天就是 if err != nil ，快赶上 C 了。隔壁 Rust 比你 Go 更 native ，怎么人的 Result 类型这么正常。都是现代语言，不要求你多高雅，正常一点总行吧。if err != nil ，这种模板代码，真的和 Java 里判空一样啰嗦……

没有 native 命，却患 native 病，是对 Go 语言最好的描述。

---

你用 Go 写写中间件挺好的，没人反对你。硬要扯业务代码全都用 Go 写，这不自虐。

您按一下 ⌘ + 空格 看看呢…… 系统自带的已经够好用了。下过几次别人鼓吹的 Alfred 之类，感觉没有什么不同。另外，很多软件底层也是调的 Spotlight 的接口。