switch 确实不错, 可以碎片化的时间玩, 启动游戏成本非常低, 游戏可以常驻后台.

@gitrebase

1. 就叫 package user, 如果冲突就 import userservice "service/user" 就可以了. 没啥不雅的吧
2. 假如 service 互相引用就说明存在共同逻辑呗, 如果是和 model 相关的就下沉到 model, 如果是通用的业务逻辑就下沉到 util, 如果都不是, 我就继续在 service 单独起一个目录来建. 实际编写过程中, 我一般不会直接创建 service, 需要复杂逻辑时才会提取到 service 里面. 否则基本都在 model 中写了.

3. 这个不是 golang 的方案, 就是我自己的总结学习的方案. 原则上遵循瘦 controller, 胖 model, 如果 model 太胖了,才会提取一个 service package.

@gitrebase

1. controller 排版有问题, 应该是 controller/user/user.go . 也就是一个模块一个 package

2. model 下面全部都放在 package model 下面. 是为了方便处理模型之间的关联关系, 比如 user 的多个 posts . 相反的 post 属于 user 也可以在 post 模型定义, 不会出现引用循环. 我自己是这么用的,写起来比较简单快捷.

```go
type struct User {
Posts []*Post `gorm:"-:migration" json:"posts,omitempty"`

}

// user 相关的方法就用接收器来写, 需要对外访问的就大写, 不需要对外访问的就小写.

func (u *User) xxx() {
}

```

3. 另外访问的层级关系需要严格限定,避免造成引用的循环. router -> controller -> service -> model 或者 router ->controller -> model

util 模块则可以在任意模块被访问的,和业务无关的通用模块

4. 不是很熟悉面向对象的内聚之类的, 我的原则是写起来和看起来简单一点就行.

❯ tree .
.
├── cmd
│   └── root.go
├── controller
│   └── user
│   └── user.go
├── go.mod
├── go.sum
├── main.go
├── middleware
├── model
│   ├── model.go
│   └── user.go
├── router
│   └── v1.go
├── service
└── util
└── helper.go

平面架构了解一下, 总之就是在项目根目录下加主要模块, 比如定时任务,就加 jobs. 需要什么就加什么模块. 另外 model 的核心库是 gorm, router 的核心库是 gin, cmd 目录的核心库是 spf13/cobra

最近比较神奇的就是,梦里面过了很久. 醒来看老婆跟几个月没见了一样.

楼上提到了矮轴, 那我推荐一下 nuphy 的 矮轴机械键盘, 我买的青轴感觉很不错, 做工精细, 适合已经体验过机械键盘的, 想来点新鲜感的

女人 30 如狼似虎?

牛逼.

从入门到放弃,确实比较难.

深圳北大太贵了, 比一般的贵很多. 可以试试其他二甲或者三甲医院, 如果不痛的话可以不用做根管,太麻烦了..

@loryyang 要根据沟通目标选择合适的沟通方式，部分场景即使是选择邮件也是不错的选择。 你可能没见过你说两句对方就阴阳怪气恶心或者脱了裤子放屁的人。

@loryyang 当面沟通效率高考虑过对方的当面沟通能力么? 你这么确定对方一定能够在当面沟通中表达自己的想法么?

感觉可以盈利了呀. 插件/皮肤/扩展 做成 saas ,或者是 open api 让有开发能力的企业进行接入到已有的 app 中增加 im. 都不错的样子

支持一下