@SuperMild 很有道理，作为一个底层人，永远不知道什么是真的，什么是假的。

@Saturn72 已经发布的语法中还没加进来，在计划中是有的～

cmdcat A -> B, B 启动 C 之后，B 自己退出， 然后 C 再次启动新的程序能够追踪到么。

大道至简?

@Keystroke 这个价位领克的哪一款车比较推荐呀.

搏一搏

校招性价比更高.

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 如狼似虎?

牛逼.

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