你需要区分 decoder 和 validator ，有的库会同时提供两个能力，但有的库只会提供 decoder 能力，你去找个带 validator 的就行了

试试 130 Byte 的依赖库 nanoid: https://github.com/ai/nanoid

看来并没有什么人帮你分析这两个方向的利弊，我来写点文字吧，不能保证准确性，仅供参考。

首先你需要明确一个认知，如果你想成为一个专业的程序员，就不要被技术栈困住，前端/后端的工种之分，只有国内区分得这么清楚，北美大厂基本会统称为 SDE/SWE 。

其次，工作是工作，爱好是爱好，你需要区分，你究竟是喜欢写代码，而是单纯地想以写代码为生？如果是前者，无论你选择哪个技术栈作为你的主力方向，都不影响你取得世俗意义上的成功，随着对技术的深入，你对代码的热爱会让你不自觉地学习各种各样的技术，成熟且专业的程序员从来都是以解决问题为导向，而非技术导向。如果是后者，那你就得从功利主义的角度做出选择，问题就变成了“在仅仅当作工作来对付的前提下，如何尽可能多地挣到钱？”，这个问题在国内语境下是存在标准答案的，也就是其他人口中的“后端”，优点就是所有人都在说的“天花板高”，“架构师都是后端出身”，不再赘述。

最后，如果你的目标是不想工作，我可以给你指出一条歪门邪道，有一个事实是：90% 的产品都不需要太强的技术做支撑。你只需要掌握一门技术 20% 的知识，就能解决 80% 以上的问题，也就是说，除非兴趣使然，你没有必要成为某个技术栈专家，只需要全都略懂一点，你就能尝试创建自己的产品，也就是所谓的独立开发者，而一个成功的独立开发者，往往需要在前端、后端、设计、产品、运营这几个方向都有一定的经验（不需要太多，20% 足矣），而这些方向中性价比最高的切入点，就是前端，原因非常简单，就是无论你的产品都多牛逼，你都得先有个界面给人用起来才行，而对于独立开发者的产品而言，界面几乎就决定了一款产品的存活与否。

最后再重申一遍，从正常的职业规划来讲，选后端。

我们团队一直在践行 BDD 实践，最大的经验就是，写测试套件要比写测试本身更重要，如果你想在团队内部推行 TDD/BDD 规范，最好花一些时间先把测试框架搭起来，很多前端代码的可测试性都很差，因为 js 比较灵活，外部依赖非常松散，导致你想对某个组件写测试，必须要 mock 一大堆东西，可能大部分时间都在折腾 mock 外部依赖，所以如果你有能力树立起团队的开发规范，收缩组件的外部依赖，并且提供统一的测试套件，这样团队成员其实是很有动力写测试代码的。

@stevenshum #12 可以搜啊，右上角不就是搜索框

试试我的： https://github.com/Yidadaa/Issue-Blog-With-Github-Action

爱用用，不用 [*]，合着开源作者活该打白工？你看着不爽自己去 fork 一份，把文档补上不就行了？

手里有一个 40k star 的项目，可以分享一些经验，搞开源千万不要试图只靠打赏，不然百分百会饿死，我不是在开玩笑。

如果可能的话，op 可以先放缓功能性开发，早早规划一下收费的功能，哪怕用 Lemon Squeezy 或者 Stripe 搞个简单的订阅，靠爱发电总有一天会耗散所有激情。

@daveh #81

我们用的构建工具是 ninja + cmake 。

我的确不清楚 CLion 这些 IDE 具体使用了什么技术构建的符号索引，CLion 相对于 lsp 建立索引的速度确实算快的，VS 和 Xcode 我用得不多，不做多评价。

我要重申一遍我的第一条回复的核心思想，免得我们的争论跑偏：
- 我主张：无论用什么索引技术，在本机开发大型 CPP 项目都很痛苦，我当然知道你说的这些加快构建时间以及最大化利用增量编译的能力，但这些能力的提升总归会受限于 CPU 机能，项目的内在复杂度会一直堆砌，尤其在 CPP 缺少标准反射能力的当下，很多功能都依赖大量模板和宏编程，这些都会极大地拖慢编译时间，项目增长到一定规模之后，无论再怎么做编译优化，本地编译时间都会不可避免地膨胀到无法忍受的地步；
- 我主张：CLion 的远程开发体验就是垃圾，你说的那些所谓的“CLion 远程工具链、Gateway 、远程 IDE 、远程桌面”我们都用过，我可以毫不吝啬地再说一遍 CLion 远程开发体验就是垃圾，尽管我们团队都喜欢 CLion ，现在都不得不迁移到了 VSCode 。我不是固守某一种编辑器的原教旨主义者，在完全迁移到 NeoVIM 之前，我用了相当长时间的 CLion 和 VSCode ，而且团队其他成员使用它们的时间更长，这不是一种臆想，这是一种实证；
- 我申明：compile_commands.json 除了首次生成需要重新编译，后续的符号索引更新都很快，但这一切在羸弱的本机上都会变得十分痛苦。

总结：我不想评价哪种 IDE 或者编辑器更好，它们各有各的好，但仅针对大型项目的开发体验而言，VSCode/NeoVIM + 远程开发机的配置是目前最优解，而且如果考虑到调试体验，VSCode 吊打 NeoVIM 。

@bugmaker233 Linux Kernel 里面都是 C 啊，C 编译起来比 CPP 不知道快到哪里去了，CPP 里稍微玩点宏、模板，引点什么标准库，编译时间就起飞了。

@daveh #78 看来你不太清楚这些 IDE 是怎么建索引的。上世代 vim 依赖 ctags 建立符号索引，非常不准确；本世代 IDE （包括各种集成 lsp 的编辑器）都依赖编译器生成的 compile_commands.json 来建立符号索引，这种索引是由编译器在编译项目期间收集的符号信息，非常准确，当然有一些静态分析工具可以使用其他方法建索引，但现在主流的 IDE 基本都是依赖 compile_commands.json ，这个文件必须要完整编译一遍整个项目才能生成，也就是你说的“编译数据库”。

其次，你把增量编译想得太好了，如果具体项目中没有做过依赖治理，各个文件之间的依赖基本就是一坨，尤其是改动头文件之后，所有依赖这个头文件的下游文件（.h / .cpp ）都需要重新编译。

最后，我的第一条回复不是在说 Clion 之外的 IDE 能节省编译时间的问题，而是大型 CPP 项目基本不可能在本机编译，只能靠专门的高性能开发机来编译，这就需要 IDE 的远程开发体验必须得好，目前远程开发这块，Clion 基本没法和 VSCode 比。

@closedevice 直接 ssh 到服务器上，在服务器上配置好 neovim 开发。

@daveh 当然可以建索引，但是建索引之前你得先编译一遍项目吧？编译一次 20 分钟，后面随便改点什么头文件，又得重新编译，一天下来净等编译了，还干不干活了。

大型项目（本地 MacBook 要编译 20 分钟以上的项目都算，无论什么原因导致的）只能在开发机专用服务器上开发，几百个核拉满，只在本地开发基本干不了活，索引都建不起来。

CLion 基本对于这种项目无能为力，JB 的远程开发体验就是一坨，团队内使用统一的 VSCode 配置，使用 VSCode Remote 开发，我自己用 NeoVim + coc 插件开发。

期待很久了，linux 上的启动器都太极客了，甚至有些简陋。

不过 op 可能需要考虑一下后续维护成本，linux/win 用户和 mac 用户不一样，付费意愿可能会低很多，后期维护会比较消耗时间精力。

王国之泪的美术设计太差劲，为了地底地图，强行在地面搞了很多大洞出来，而且地底怪物长得是一个比几个丑。如果有可能，我觉得把地底拿掉，然后专注扩展天空地图，这作虽然开场是从空岛上飞下来，但是天空地图少得可怜，空岛的美术设计比阴间地底强太多了，而且立体地图的可玩性也更强，甚至地面的洞窟都比地底好玩。