昨天早上突然发现测试服务器空间满了，用du挨个文件夹查看，发现是php debug log占地极大，有的log直接有1G，打开后发现极其多的php stack trace.
立刻到主服务器查看，主服务器日志也400多M的日志，幸好主服务器空间足够。
那么多stack trace,可以肯定之前是没有的，挨个查看日志，是某一天早上一个时刻发生的。
立即学习“PHP免费学习笔记（深入）”；
解决方案：
1. 难道是之前升级php导致，到网上搜索php stack trace,所有的都是显示如何打开，却没有如何关闭的。仔细查找php的参数，只找到ignore_repeated_sources和ignore_repeated_error这两个看似有关的东西，更改后也不顶用。
2. 如果不是升级php所致，再仔细想这几天做了什么 改动，哪些是和php trace有关的，想起xdebug. ，先尝试把xdebug删除，OK,问题消失了。肯定是xdebug的问题了，开始的时候没有直接找xdebug的官方文档，利用phpinfo把xdebug所有的参数都打出来，先猜是哪个参数，试了几个都不顶用, 后来才静下心来看看xdebug的官方文档吧，发现了如下话语：
Stack Traces
When Xdebug is activated it will show a stack trace whenever PHP decides to show a notice, warning, error etc. The information that stack traces display, and the way how they are presented, can be configured to suit your needs.
有戏，再继续找，发现了一个名称和用途你如何也联系不上的变量"xdebug.default_enable",还真就是这个参数来控制了，如下。
xdebug.default_enable
Type: boolean, Default value: 1
If this setting is 1, then stacktraces will be shown by default on an error event. You can disable showing stacktraces from your code withxdebug_disable(). As this is one of the basic functions of Xdebug, it is advisable to leave this setting set to 1. 这个问题几乎折腾一天，心得：碰到意外问题时要冷静，虽然影响了多原有计划，但如果问题是严重的问题就一定要排除万难先解决了再说，不然会形成习惯。另外，使用一些现成功能模块时，在在最衩进行搜索无果后，得静下心来仔细阅读官方文档。
