综合上面的回答，可能适合的方案还是服务的“常量”代码抽成一个包。

1.抽成一个公共包，各个服务引入调用即可。 2.做一个配置中心服务，所有服务统一读取同一份配置，做好更新和兜底策略。好处是修改配置不用发版，在配置中心改一下就可以了。

需要一个 common 的基础包

一般是吧这些和 idl 绑定，idl （比如 pb 描述）生成这个仓库，各方来引用 不过怎么说呢，没必要强行微服务。特别是 python 。python 4 个服务一个分 1c 。还不如一起在 4c 的机器性能好

你这就属于，想用微服务规范和隔离开发，但又已经看到微服务最大的蛋疼。 最好 code reviewer ，你说的问题都不是问题。monorepo 又不是想怎么写怎么写

@iyaozhen 微服务是既定现状，前人拆分的，至少已经快 8 年了，暂时没资源去改回单体。

common 包用起来其实没那么方便，远远不如代码里直接写一个 const 来的简单。

@sampeng 几乎没有 code review 。 说得难听点，现在最好的 "code review" 就是测试 + 一上生产环境就挂掉。没埋雷，半夜爆炸就不错。 所以，我才想多引入一下非人工的花销来尽量保证稳定。比如： 1. type hint 。有点作用。 2. 写 DTO 而不是一个 dict 满天飞。不然回头维护的时候很慢热，记不住 key ，经常导致 KeyError 。也算有点作用。 3. 常量共享而不是用到就“手抄”一遍，这种手抄还会抄错。 不怕各位笑话。我们还有一个“运行时的常量共享方案”是这样的：每个服务提供一个接口返回本服务的一些常量定义，然后服务启动的时候，去请求一遍这些常量定义。 我感觉是很难用。运行时、纯动态，你写代码的时候，根本不知道自己引用的值存不存在。IDE 也无法给你补全。

抽出来打一个 common 包，每个服务引入即可。 common/ ├── inner/ │ ├── dto │ ├── vo │ └── ... ├── outer/ │ ├── dto │ ├── vo │ └── ... └──

我的偏好是只把用到的或可能用到的再写一遍，可以硬编码的就直接写再放个注释。费点力气但是感觉体验很好。如果复用很强的再抽到 common ，因为不喜欢跳来跳去😁