这个一开始是从 binary protocol 那边过来的，不过那边不叫粘包
叫 message parser 或者 message pack

简单来说就叫组包、拆包，这本身就是属于 protocol 层面的问题
N 年前某一天，突然听到粘包这个词——找了老半天还是没反应过来

反正国内有个神逻辑，不管我做什么，都是为你好
给你一巴掌是为你好
工资倒挂是为你好
。。。。

80 后总人数两亿多，楼上要不要统计下混得好的能有多少
说不好听的是，80 后什么都赶上了，又什么都没赶上

我们这边原有技术栈主要是 C++/Java ，目前新业务、产品基本都转 Go ，当然业务主要是 toB 的
涉及有物联网（节点、网关 /边缘、云平台都有）、资产管理、财务类（主要是第三方系统对接——如金蝶等）

工作流确实没有合适的，但基于某个开源的半成品自己维护也可以解决问题；别的小规模的轮子，自己造速度也很快，且相对好维护。而且只要有愿意转 Go 的，转了之后都不太喜欢考虑继续写 C++或 Java

对于 api 或 crud ，基本都是通过代码生成框架代码与 model ；对于 model 部分不满足的，做些定制化开发
所以实现是否优雅某些情况也不显得那么重要

云闪付+1

其实现在买是不太建议，真要买建议再等个半年或一年

@zhongjun96 #99 这个应该不用在直系亲属放 6 个月以上。去年底有个之前同事凑首付（广州），也借来几万，是直接转同事父亲卡上，然后他父亲转给他就可以——不要求六个月以上

若是针对扩容与复杂度的话，建议了解下分布式数据库，如国内的 TiDB 之类的

当然，你游戏场景的这不算太复杂；分布式数据库之所以提出来，是因为基于传统的 SQL 数据库，在数据量海量情况下，要做在线或离线数据分析所以额外的大数据分析之类方案结合进来，会导致异常复杂

另外，对于某些说 go 的基础设施不齐全之类（如限流、监控、负载均衡、调用链等），
真心建议去了解下 k8s ，还有服务网格

路过，还是想问下说业务复杂的各位，
除工作流之外，正心请教还有哪些属于各位说的复杂的业务？

当然，若是没用微服务来拆，一把梭哈做个复杂的单体应用——这样的情况不用回答，我承认是非常复杂

珠海没啥玩的，建议不用来了
要喜欢吃的，建议去顺德。。那边私房菜是真的好吃又便宜

从业务流程入手，先主流程，然后次级别流程
不要关注过于细节的问题，容易只见树木不见森林

C++的代码维护过无文档，注释牛头不对马嘴——代码量十来万的几个项目，都是这样的做法；相对来说是最快、最有效的

tailscale+1

mac = window + linux

@codermali #3 还好可以关闭，不然就计划不用支付宝，统一转招行 app 或云闪付去了
阿里系的真的是把客户往外赶——真不知道什么神奇逻辑

go 写小工具、小服务很适合

路过。就干看热闹，大家努力