你做技术选型还知道 分析需求，结合自身团队能力，列一堆 pro.con. 然后选一个勉强合适的呢，为啥会认为手机是可以比出个优劣出来.

我不认为 set(手机) 是可序的

ov 从现在市场表现看，自然有别人会在乎的价值，追多是我们不认可而已

对的 explorer 的问题，发现卡就重启下 explorer ，我一直这么用，待机几个月没问题

把 刮削 都关了就行了，可以自己写个 script 生成 .nfo, 和视频放一起就行了

直接上 wasm ，语言 Actionscript/go/rust/c/c++/zig/lua/python/... 就都有了 🐶

@thevita 我能想到比较像的场景 eg：

比如我们有一些业务动作，可以前端直接触发，也可以有个 scheduler （ cron 等）调度触发

我想一般的做法这些 “业务动作” 属于 ”业务层“，而前面的 rest api/ scheduler ， 只是这个业务 对外暴露的两个”前端“，所以逻辑上，这两部分应该是完全分开的，只是这两者可能存在事实共享部分代码（比如数据结构等），那可以用一些具体的技术手段来解决，所以我认为应该是逻辑上先得分开，再考虑能不能共享部分代码（因为这两部解决的问题不一样，先理清业务关系，考虑共享代码，只是为了解决，这块领域知识的维护问题）

关键是这个 “如果后端需要主动调用这个接口执行一次相同的任务” 吧，这里初步看，应该是业务设计的问题，

op 这里纠结的就是 是在这里用某种通用技术实现一个 通用的“重放” 方案呢，还是各个业务自己搞

我是没看明白 管理模块 为什么要重放，倾向于认为设计错误

场景我其实也没完全搞明白，只能说下经验：不要把技术设计和业务设计放在一起做

说你给他介绍个北京 3W 的工作，让他先辞职，然后让他买个课，就是是入职前培训

不分，把权限做好就行了

@bianhui 这方面 tidb 反而是优等生吧，生产部署不说，developer accessibility 是其他国产厂商比不了的优秀，至少不会吧文档锁起来.。。。。。。

对于开发测试来说 tiup playground 可以一键拉个测试环境出来

要布一个测试集群也不复杂，如果有 k8s 还 提供 operator

他这乱七八糟的命名感觉去看他文档都搞不清，翻了半天，分享下，不一定对

GaussDB 是 一堆产品矩阵和解决方案，你这里的 Enterprise 版本，应该是 基于 openGauss 的企业级版本？(实在不确定，想吐槽，为啥产品里一堆叫 GaussDB 的）

如果是, 按他文档的说法，openGauss 在应用端基本是兼容 PG 的，有一些 “企业扩展包” ，如果不用应该直接用 PG 来开发应该也是可以的

也可以用 openGauss ，这个提供了 Docker 镜像

另外方面，如果是使用的分布式版本/复制版本，要考虑表设计的，这个你绕不过要去了解一下，他文档中心提供了一下开发相关的特性说明和 推荐的“最佳实践”

这里 有 两个地方有文档 一个是华为云，对于应用端，我想差异应该很小，另外有个 “文档中心”，不过这里要部分文档要客户才能看得到。。。。

微信最初的版本 大小 457KB
现在的微信已经 奔着数百兆去了

而他核心功能基本差不多

我在内部工具平台小规模场景下用 docker host mysql 很多年了，没什么问题.

至于说 生产环境 DB, 的问题主要还是运维的复杂度，但这个问题不是 docker 带来的，你独立部署也会带来一样的问题啊，只是 仅仅一个 docker 给你运维这种服务没有什么帮助，甚至由于与既有运维工具链的兼容配合问题，会更加复杂和麻烦.

你裸部一个 mysql 用来做生产问题也很大啊，只是出问题有很多资料帮你解决，所以还是 运服务吧，或者 用 vitess 这样的

@thevita 哦, 是只 checkout 某个 文件夹, 看漏了，忽略我吧

GitHub 当然首选用 git 啦
至于使用方式，稍微在 github 翻一翻: https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository

只卖这一个组件感觉不好卖，有现成数据的团队大概率有一套平台，类似功能都有（好不好用另说）
得找准用户（非程序员，有数据分析需求，对 Excel 类产品熟悉），形成面向场景的解决方案才行

自己个人用的话，各显神通，各种 registry 不过是顺带而为

生产用的话，自建