今天线上出现了一个字符超长引起 mysql 抛出异常的问题
问题本身不大，上游系统有 bug，传递的字符串没有做 trim 处理，导致报文节点中的字段远远超出预留长度
反应给领导的时候，领导对我的汇报并不满意
我说，这个问题是由于上游传下的数据过长
领导说，这是表象，出现这个问题的根本原因是什么？为什么在上游传下来的时候没有校验住，而使错误的数据流入系统了引起报警呢
之后的对话有点记不清了，我提出这个校验应该由上游系统做，于是叫来了上游系统的负责人，在一旁的组长也加入了讨论
讨论中大体涉及到了如下几点：
- 错误的数据是前端下传的，还是系统 bug 引起的
- 前端控件是否有限制，是否有校验，是否有提示
- 是否应对数据长度添加校验
讨论中还是感到了自己表述能力的匮乏。讨论中提到的点，我也大都能想到，但是当我向领导汇报的时候，我似乎只能说个，上游系统问题，上游应当校验，听起来倒有点推卸责任的感觉
我所思考的内容是：
这个数据到本系统时，已经分发到了多个其他系统，所以类似异常数据的处理，肯定不在本系统做，做了其他系统也要做，如果处理逻辑差异较大，会造成数据不一致
而上游若要对字段长度做校验，那理论上所有字段都应该校验，但是关于数据长度，要么业务上有明确的限制，比如评论限制 200 条，那么底层保留两百的长度，这种校验则应在前端就有所体现，校验逻辑应当在前端直接提交的服务端有所体现。
而如果没有明确的业务上的长度限制，如用户地址，理论上，用户想输入多少就输入多少，但是正常情况下，地址信息的长度是有限的，最详细的地址比如身份证上的地址，长度也是有限的，要保存数据的服务端预留一个长度即可，如果加上校验，则很被动，一旦出现真实的而又超出系统限制的字段，不仅需要修改数据库的长度，还要修改代码中的校验长度，无法快速的让正确信息保存下来
所以，对于本次问题的结论，我想应当是：
上游修正 bug，其他系统不动
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于