@Nitroethane #25 原来是这样，谢谢。

@Nitroethane 这样写有什么不好的吗？

我们这样实现的主要目的是不需要任何网络请求，在那些没网的环境下，只需要拷一个 index.js 就能跑了。

不要相信学 go 一天上手这样的说法，如果你有其它语言的知识背景，倒是可以快速上手。

@capgrey 从哪搜出来的？用的什么关键字？ google 和 github 上搜 create-go-app 都找不到才对。

其实你可以反过来，不创新了，等着抄他的。

多年前卖掉 100 多个币买房的，不也还好好的，没什么大不了的。

我已经习惯了，从来不相信他们的文档，也不相信他们的测试沙箱。

好像一般只封端口，换个端口就可以继续玩了。

销售是有成本的，客户维护也是需要成本的，如果这个成本高于收益，那就不合适了。

@gowk

在我看来 if err != nil 反而是一个好的东东, 有错误就直接返回，写逻辑都简单多了。

```go
/ Create create user
func (r *UserController) Create(c *web.Ctx) (any, error) {

user := model.CreateUser()
defer user.Release()

if err := c.TryParseBody(user); err != nil {
return nil, err
}

if err := validator.CreateUser(user); err != nil {
return nil, err
}

if _, err := proxy.CreateUser(user); err != nil {
return nil, err
}

return user.ID, nil
}
```

其实 go 用来写业务也很适合，有很多现成的工具可以用了。

代码写久了，总会写些小工具来减轻压力的。

我们也弄了个叫 gskctl 的东东，根据实体生成 restful api 代码。（广告）

强，一直想把项目中的 type Next func(c *Ctx) (any, error) 换成 type Next[T any] func(c *Ctx) (T, error), 但是好像影响比较大，一直还没敢换。

@cannotagreemore 确实是 Capacity 的问题。

关键看路，如果全程都有绿道就爽了。

简单问题复杂化，太闲了。

如果只是需要能直连，用 aws 的美西主机就可以了，速度还不错的说。

如果要求稳定直连，最好是备案，两地部署。

不上班的自由也仅仅是以为的自由。

上班做的是公司的那堆事，不上班做的是客户的那堆事，只是换个服务对象而已。

自己搞个光猫有什么好处？或者说有什么可玩的？

能体会你的感受，就像一个爱干净的人和一个不爱干净的人一起租房子一样。

我们公司的代码规范是从下往上推动的，基本上统一了公司的代码风格。