我觉得微服务还是不错的，看你怎么用，一个大服务器，分成 n 个小服务，各自对外提供服务 api ，部署灵活，维护简单，团队人员也灵活，总之，看自己的业务量，业务量单一的，可以不拆分，但是业务繁杂的，建议分开，并不是非要用流行的微服务那一套架设，就按系统分为一个一个的单体服务就行。

@junwind 容易点错了，就发出去了。接着说
- runtime // 运行时产生的数据，log 也可以放在 runtime 下面
- upload // 如果有上传文件的，可以放这里，或者走 oss
- main.go
- 部署脚本，或 dockerfile 这种。

@junwind
- api // api 接口层，暴露，外部请求的接口，流入这里
- homeApi.go
- loginApi.go
- logic // 业务层，实际的业务在这里处理，由 api 调用
- loginLogic.go
- dao // 数据层 ， 数据的 curd 在这里处理，由 logic 调用
- conf // 配置，如果配置多，做目录，如果配置少，一个单文件即可。
- routes // 路由 ， 如果全部走默认的路由规则，可以不需要
- log // 日志
- runtime //

按你需求，不需要框架啊，直接自己撸就行， 建议前后端分离， 前端 vue+uniapp ，go 直接抛出接口。 目录结构大概这样就行：

没有什么特殊要求，是可以平替的

@21231sv 数据库 io 瓶颈

落地是另一波人事情，这波人不管落地不落地的，不妨碍拉投资，把钱放口袋。什么元宇宙，VR ，AR ，都没落地啊。包括汽车的自动驾驶也没完全落地的，普通人就老老实实当牛马，顾好自己的一日三餐就不容易了。不用操心落不落地，AI 目前我编程当辅助用的。

@seers 可惜没有 mac 版本

自己定义一套字典呗， 比如 a 表示 xxx ，b 表示 yyy ，然后把这套字典交给要解析的对方。

@Dcrclub 很有同感，就是故意为之，比如 laravel 框架，什么任务调度，不就是定时任务吗，什么事件监听，不就是一种埋点吗，有些东西，换个名词，就高大上，很多所谓的专家就是吃饱了撑了，故意让你看不懂，然后提升自己的逼格。

这种千万千万不要想着重构，能跑就行。

@realJamespond 这个不是给程序员用的，是策划用的，excel 表配置走 git 管理。

@sephiroka 我也觉得 jb 加的好用，但是给策划安装这个，太占性能了。