MySql 编码字符集不支持 emoji 表情

这个问题算是一个很古老的问题了，早在几年前刚入行就遇到过。

解决办法：

1. 修改表的编码格式，这个对与生产中的系统基本行不通，即便可以，也不建议，可能造成想不到的问题。因为可能导致不同的表使用不一致的编码格式。

2. 将需要存储的字段内容 insert 前使用 Base64 编码完再存储，使用时再对其进行解码。

代码评审相关一些问题

未排查出关联的查询影响

Mybatis 没有严格遵循公共代码复用要求，在一次上线代码评审时，一个 Mybatis 的 Mapper 增加字段查询， 关于 BaseColumn、BaseResultMap 中的字段增减后，如果大家规范复用重复代码片段，也就没什么问题。关键是有人在其他地方用了自定义字段修改，且引用了 BaseResultMap 造成上线后报错。

评审发现的逻辑漏洞修复后引起其他地方报错

关联评审不足，代码修改需要严格考虑到所有引用的地方都没有问题。因此充分的测试验证很有必要。

CRUD 看似简单的功能，但是如果揉杂业务逻辑，则一处修改，其他关联的数据生命周期操作同样要跟着修改。

这里也暴露另一个问题，代码评审尽量前置，而非在上线前，因为上线前如果评审发现问题，留给修复验证的时间就太短了。

Copy 的代码块中隐藏错误的传参

同样的逻辑多处出现，但是入参枚举对象不同，而在修复时单纯的 copy,没有做细致的评审与测试。导致业务流程错误。规避该类问题，则需要慎重对待代码的复制，通常相同的逻辑不能进行复制 copy 而应该抽取公共的方法避免相同代码块出现在不同的地方。另外就是对待代码的细致程度需要做到字符级别的书写与审查，而不是按照单词甚至整行粒度进行确认。人的眼睛很容易忽略一些你自己不想看到的内容。

系统交互上的可用性确认不足

下游系统的是否可用不能单纯通过言语描述进行确认，仍要增加测试验证。下游反馈传特殊字符没问题，但是实际上线后确出现故障。这里边有一定的信息量丢失问题， 传递特殊字符是哪类字符，是否可用有没有经过检验，对方的可用很可能与你相像的不同。因此必须进行验证通过后方能上线使用。

结合第一个 emoji 表情的问题，同一个公司的不同系统大都遵循相同的开发规范，如果自己系统因为表情无法存储出现故障，多半推送至其他系统之后会存在相同的问题，因此不能在口头上进行确认，必须辅以真实的数据验证。当然这里也有时间工期紧张的因素，因此问题的产生一定要多角度分析根因。

Kafka 消费客户端报警信息标示不足

生产与预生产环境的消息配置相同，但是关键信息没有标示，导致报警后错误排查了环境，长时间找不到问题，最后发现环境排查错误。此处因为错误的配速误导，误认为预生产环境的配速一定高于生产，结果其实相反，造成误分析环境。