每天早上一睁眼，习惯性的打开手机看客户群里有没有反馈或是发现新的bug，对于bug早已司空见惯，任何开发者都不欢迎这讨人恨的东东。
今天虽然是周末也是开学季（好像发现了什么，^_^）,但也不例外，每天早上第一件事就是查看有没有新出炉的bug(我也不想写bug，之前写项目老是粗心，没有去年的细致，具体原因不细表)。
打开微信，按照习惯查看新信息，一看到客户截图显示服务器异常，心里凉凉了，因为跟IOS和安卓沟通好了的如果HTTP状态码为500就提示‘服务器异常’或‘网络错误’，这种情形第一时间想到的是又出bug了？但细想又不对，随即打开小程序（这个客户有三个端），我勒个去，一切正常，WTF，玩我呢。
有一个很简单排查（丢锅）的方法，如果前端出现一样的错误，大概率是后台的锅，反之，如果前端同一个操作或功能一个正常一个不正常，大概率是前端自己的锅。
这次应该不是我的锅了吧！然后打电话询问一下是怎么回事，把经过叙述一遍，安卓也懵逼了，不会呀，大家都没改动。二话不说就开始排查错误。
这种情况只需要再调一次API就知道了。很多时候，大家只关心API返回的错误码或状态码，都忽略了HTTP的状态码，如果返回了数据，就直接拿数据。（ps：API的状态有的人放在header里面，有的人放在返回结构里面，也有的人直接用HTTP状态码，优劣各自评断）
安卓告诉我拿到数据了，但是HTTP状态码是500，WTF，这什么操作，服务端用的TP5，如果返回500的话会抛出异常的，因为出现500或5XX大多数是语法错误，这种情况下不可能有数据的，深思之下想到了6月也遇到过这种错误，当时是用postman测试的，HTTP500但有数据，当时只是用屏蔽错误的方法应急了一下，难道是同一个原因？不管那么多，先让APP正常运转再说。
按照上次的解决办法，我在同一返回的方法里面加上了
error_reporting("E_ALL");
ini_set("display_errors", 1);
header("HTTP/1.1 200 {$msg}"); // ok 正常访问但是这样也不行呀，必须得找出缘由，随即向老大请教了一番
以下是对话
：
查看了一下这个文件，是写入日志
导致错误的根源就是
return error_log($message, 3, $destination);在记录错误日志的时候出现了错误，然鹅翻了TP5的日志一无所获，然后
再然后
就没有了，
