不可能存在 0 warnings 的代码，比如："Return value of the method is never used", "Parameter is never used" 这种是无法避免的，有究极代码洁癖的 antirez 写的 Redis 源码里也有一堆 warnings ，但这不代表就是代码质量有问题，纯纯的 IDE 无法理解

恐怖如斯

强转 Go 是不太明智的选择，如果我是面试官，候选人从其他语言转 Go 没写过生产项目，那大概率是低录用优先级。

最好是有一个合适的机会，比如，公司内部有 Go 项目缺人，可以转过去试试水，也不用担心试用期被裁。

可以把文件传到云文件服务，比如：阿里云 OSS 、腾讯云 COS 、Amazon S3 ，最便宜的一年 10 块钱左右吧。

如果有后端服务，且文件比较小，可以通过 HTTP 接口直接返回。

@shilianmlxg
@xiangxiangxiang

复杂度具体要看你们业务需要实现的细节，一般来说前端可能会稍微复杂点，比如：消息重发、消息撤回、消息已读、客户端拉取离线未读消息、客户端过滤重复消息等。后端主要考虑集群高可用、消息 ID 生成算法、消息持久化。

具体的思路就是保持每个服务的实现简单，尽量不引入中间件增加复杂度，Chat API 只负责 CRUD ，Chat Server 只负责消息推送，保证这两个服务可以单独使用互不影响。


因为是给集团设计的，所以不太方便直接拿出来给大家看，现在手头上也没有现成的设计方案，可以弄个语雀文档，把我加进去，我有空把各个功能的细节写一下，大家一起设计。

不需要保存聊天记录的话，直接 websocket + protobuf 就可以了。

如果要保存聊天记录那就复杂了，需要一定的开发成本，推荐使用商业的 IM 解决方案。

如果项目内容比较敏感，需要自己开发一套系统，可以参考这个：
把服务拆成 Chat API 和 Chat Server：
- Chat API：负责 CRUD ，无状态，可以动态扩容，主要性能瓶颈在于数据库。
- Chat Server：负责保持长连接，推送消息，通过注册中心相互发现，或使用 Peer to Peer 方式相互注册和推送消息。
- DB：推荐 MongoDB 之类的 NoSQL

理论上，Chat Server 只需要 2 个实例就可以保证高可用和十万级连接数，只需要传消息 ID ，所以报文很小，使用 protobuf 通常只有 20 - 50 Bytes

https://i.v2ex.co/bN9v765l.png

idea 插件 Maven Helper

边缘计算，人脑领先行业几百万年

好消息，新版本已经弃用 ZIPLIST 了

#define OBJ_ENCODING_ZIPLIST 5 /* No longer used: old list/hash/zset encoding. */

https://github.com/redis/redis/blob/6686c6d774fcf71fffbaeff798c997ab3eff80de/src/server.h#L840

等 JetBrains Fleet

换一个思路不知道可不可行，提供一个 Web 页面，客户提交信息到服务端，然后服务端渲染 PDF 然后再打印，这样就不需要开发客户端了

很简单的道理，如果你是直播带货的大佬，你会考虑把钱分给别人赚吗？反正我不会

具体问题具体分析，像国家这种数据，启动服务实例时，直接存在本地内存也没关系，因为不可能会出现下一秒就多一个或少一个国家情况，当前，为了以防万一可以加一个刷新接口。

城市也是一样的，可以把热门城市放在本地内存，其他城市可以走缓存或数据库。

这也能争起来，感觉大家工作都不太饱和

作者通过“教程序员如何赚钱”赚到了钱

996 还 WLB ？

aws 可以白嫖一年

不安全，不光是 DDoS ，还有这些应用本身可能存在的问题，几年前因为 Redis 的漏洞，服务器被挂挖矿了，全组绩效不及格。