不分，把权限做好就行了

@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 不过是顺带而为

生产用的话，自建

可以认为 slice 是一个 指向 array 的 fat-pointer

不能导出的是 inner 这个类型

func New() inner {} , 这个函数是 导出的, 这里的可以理解成一个复合类型

就像

struct Struct {
inner inner
}

这个 Struct 被导出了，但它作为一个复合类型，内部引用了 inner 一样.

"我一开始以为什么样的结构能管里这么多的不同项目放在一起；"

这里的项目应该是 维护给不同 客户的不同版本，包含类似定制专有逻辑这种吧？？

如果是这样场景的话，不就是 feature flag 么，很 make sense 啊，在合规的情况下，尽量减少 long-lived branch 带来的维护成本呗

当然，一般这个 feature flag 会配合编译系统食用

@fakepoet

同 pyenv + pyenv-virtualenv ,
支持多种 venv 后端（具体是哪做的我也不是很清楚）, venv, virtualenv, conda 都支持
也能 用 python-build 安装 和管理 standalone 的 python

就能实现各种环境都在一起管理了

大部分机遇 几个 python3.x base ，派生一堆 venv

ai 的场景就 用 anaconda/miniconda 作为 base, conda 作为 venv 后端 管理具体的 ai venv

本质应该算是后端的非主流半吊子前端来说下：

我会习惯按业务逻辑相关性来放, 不通用 但 一起完成某个相关业务逻辑的放一个目录下
如:

..../(some biz)/
..../(some biz)/list.vue
..../(some biz)/detail.vue
..../(some biz)/edit.vue
..../(some biz)/useHost.ts
..../(some biz)/popupList.vue
..../(some biz)/mergeToolDialog.vue
..../(some biz)/useBizLogic.ts -- ( 只是举个例子,一般还是会叫具体完成的事)

cherry-pick

歪楼:

“三个分支代码基本是一样的，只是里面可能部分标记环境的变量不同“
这种情况应该首选通过 flag 来实现

手动处理最大的问题是: 一段时间之后，就没人知道这三个分支 除了 “部分标记环境的变量不同” 外是不是真的完全一样了

再次的选择:
引入一些 自动化的工作流, 如: merge 到 dev 的 feature 合并后，自动创建 到 uat, prd 的 mr

看了下 go ，支持还是不错的，应该上调, tier 1.5 - tier 2 吧，不过确实有很多点需要自己去 take care 的

理论上，能完整支持 c abi 的都可以

tier 1: rust, zig

完整的 C ABI 支持，完全的互操作性，交叉编译支持非常好, ps: zig 还带了一个 c/c++ 的前端，配合他自己的编译器后端 可以非常方便的实现 大部分 c/c++ 代码的交叉编译，而不用自己去搞定 c/c++ 的交叉编译环境，我用过他来作为 cgo 的 c 编译器，而不用去配置 ci 的 c++ 环境，也能在 mac 直接交叉编译输出 带有 cgo 的 linux elf ，推荐

tier 2: c/c++/pascal/ etc...

完整的 C ABI 支持，完全的互操作性，就是交叉编译麻烦

tier 3: go

用得很少，看文档描述，也能实现，但因为 c abi 存在栈拷贝的开销，大家都不是很满意，而且我有些疑问：在 存在 gc 的情况下，怎么保证 go 对象 export 给 c 之后的安全性？


tier 4: 其他

理论上 类似 python 这种，也可用 用一个 c wrapper 包一下来实现，python code -> c-wrapper -> python code [decompressed from shared library/dll]

WinHex https://www.x-ways.net/winhex/index-m.html

等一系列硬盘取证工具，包括 X-Ways 家的取证套装，不过紧急是进行这个完整备份的话，WinHex 应该就是最佳选择了，小巧、久经考验。