这是在写 APP 还是服务端？

这个责任不应该由你背负。测试人员给出的错误测试结论误导了你。

尽量自己写测试工具，实现自测功能不要过于依赖测试人员结论。

一个 App 是多方博弈的结果，不是程序员决定的。

我不准备正面回应你的问题，只想谈谈这种设计引入的成本和风险。

根据上述设计，存储前必须要先计算标题 MD5 值，连接 Redis 检查 MD5 是否存储，最终存储到 SQL 数据库。

计算、时延成本：
首先，计算 MD5 值十分消耗 CPU 资源，其次查询 Redis 将引起额外的网络时延，保存新的 MD5 也会产生网络时延。

单点风险：
由于 OP 仅部署单个 Redis，整个系统存在单点故障的风险。这样的系统无疑极其脆弱，一旦 Redis 崩溃将导致业务中断（无法保存新的文章），因此必须再增加两台主机来构成 Redis Sentinal 集群，成本将大大增加。

编码、调试、诊断困难：
必须在本地环境配置 Redis 服务器方可调试，同时需要处理 Redis 请求失败的情况。生产环境一旦发生异常，不容易诊断。

维护成本：
需要额外维护三台 Redis 服务器。

@WordTian I feel pity for you.

应急写代码？有什么问题是重启不能解决的？

这后端太不称职，数据表设计有严重缺陷。

应该有两种文案：

1，新成员视角：Welcome to the team!

2，老成员视角：XXX has joined/left the team.

外键约束已经被业务唾弃。

愿意付费优化可以私信我。

巧了，黄牛也是这么狡辩的。

@cnbobolee 配置信息和信元交换格式是两回事，XML 传输了大量不必要信息。

随便找家邮箱配置 SMTP 就可以发信，你这量小着呢。

非全日制的程序员要被楼主一棒子全打死了。

这一届程序员真不行，连跟随用户手机壳变换 APP 主题都做不到。

很奇怪，你先试试导出堆栈。