在我看来就两点：
一，引流，让用户引用户，因联系目标而被迫使用；刚开始的那几年，长辈可以学会微信，但是 QQ 用不来，而长辈用了微信，晚辈就只能也用微信去联系，领导同理。
二，政务民生，让用户无法拒绝使用；现在翻一翻，公共交通、银行医院、政务，公告通知、功能业务等都放到微信里，其他地方不好用或者直接不提供。

垄断忍了，但是垄断后还做成这种屎样，真的是每天被迫吃屎。

用着 1.1 GHz 的 MBA 做开发，每天都想砸电脑 🥲

在 macOS 上打开钥匙串，你能发现里边满地狗屎，各大厂写了很多记录项

@killva4624 #3 konga 官方版支持的还是 0.14 的 kong ，但现在 kong 都 2.8 了…… 主要功能还可以使用，但个别功能的接口已经变了

UI 看起来不错，要是开源社区有人能给 Kong 做个面板就好了 🍋

@WilliamYang 我目前是把公共的放 pb ，方便多处引用

喜欢第三张！ aWhhdGVyZWdAcXEuY29t

感谢楼主提供这么方便的软件，真希望 Windows 也能用 😄

重新看了下楼主提到的 https://rakyll.org/style-packages/ ，里边的指导也是有道理的；统一的 model 对 go 来说不太好——这个设计我确实是从 php 带过来的 🐶
按功能划分的话，如文章所述，User 是放在 service 下的，那就应该是和对应的接口定义在一块，看起来也没毛病；那么需要考虑的是会不会出现跨 service 引用模型，实际业务里已经有这种场景存在了，对此，难道就放到 proto 里？似乎可以的样子 🤔
---
#2 VO 、DTO 这种概念应该是来源于 Java 吧？我比较反感这些。类似的还有接口的定义（ I 前缀），接口的实现（ IMPL 前缀或后缀）。有段时间我也给接口加了 I 前缀，后来一次迭代里又全部删掉了，随 Go 标准库，根据实际情况用上 er 后缀 😂

抛砖引玉，谈谈我的个人意见
AddUser 依赖的 User ，不属于 controller 也不属于 service ；我常用的做法是把 User 放到 model 下； controller 负责把 Raw Data 转为业务模型，再传给 service
model 下的这些模型，有的模型是数据库模型，那么会顺便为其配置相关 Tag ，包括但不限于 gorm Tag ；有的模型只是功能模型、中间层模型，比较简单
除了 model ，还有一种场景是在 proto 里定义 Message ，这种情况其实和 model 也类似，可以简单视为换了个包名
结论：如果是某一层专用的结构体，会单独放在这一层下；如果是全局通用的结构体，一般放在 model 下；如果是跨项目通用的结构体，放在 proto 下；其中，第二、三种我用的时候没有很强势区分分界线（虽然感觉并不太好）

@CKR #15 现在的场所码全部是小程序码吧，这种异形码目前应该没有第三方可以解码，只能通过微信；垄断的垃圾玩意

现在办宽带，运营商都会强调城中村版，如果合同上有注明城中村版的字样，投诉到工信部还有用吗 🤔

周末不算，工作日在公司食堂吃饭，还一直买零食饮料往家里带，花不完 🐶

@bugushi #11 腾讯 - 腾某 - 腾 X ，微信 - 某信 - X 信，QQ - 某 Q - XQ

密保问题辅助邮箱都不能用，翻回国内解决人脸识别却没触发异地异常登录，腾讯的安全措施 👍
一个客服都没有的公司，不抱啥希望了，别把鸡蛋都放一个篮子里就对了
---
@doresu #8 腾 X 腾某，X 信某信，XQ 某 Q

@er567 #15 更深一层，以前因为楼下就能取快递，所以快递员放楼下也就不在意。但是现在放到菜鸟去后，虽然我能投诉，可是投诉后来派送了，这时候家里没人怎么办？让他指定时间段内派送一般不行吧。唉，一个人住的烦恼。

我更想知道如果我住 1 栋，快递被放到 13 栋怎么维权 😑

会不会是维基根据 UA 做自动跳转，谷歌爬虫被指去了移动版 🤔