雨润心灵，哲思天下

上周有个任务是要出一个重要的数据统计表，并自动发送mail，大体过程是读取并分析数据文件，根据预定格式以表格的方式展现，然后发送mail。实现方面分以下几步：读取文件—组装table—设置mail参数—调用php的mail函数发信。开始做得非常顺利，后来统计表的格式有所变化，增加了一些列和数据项，并将其中几个以％为单位的统计项改为‰，没想到这一改就出了问题，出来的统计表中莫名其妙的多了几个？！之类的符号，而且出现的位置都很诡异。肯定是html解析出错了，想到几种可能：

1.编码问题，UTF-8与GBK的纠缠不清，这包括apache服务器的编码设置、html页面的编码设置以及数据文件的编码

2.html组装时有地方不对，如忘记关闭等

3.数据文件中有脏数据，特别是有可能是全角字符只删除了一半等情况，特别的，那个千分号是全角字符，而%是有半角字符的，在%的时候又没有出现问题，于是对‰的出现表示深深的怀疑

于是一一排查，越查越郁闷，始终如此，逐渐有目的的排查开始变得漫无目的、什么都怀疑了，时间在逝去，到下班还没搞定，而报告第二天要出，回来吃完饭到宿舍都11点了，但必须继续，硬着头皮来了。有些问题已经可以排除了，跟踪到最后一步调用mail函数之前的输出是完全没有问题的，copy要送往mail函数的内容到vs中查看，完全没有问题，说明数据文件没有问题，html构造也没有问题，但开始怀疑其他问题：mail函数靠谱不，是什么机制，邮件客户端靠谱不？再就是编码的问题仍然不能排除，总之怀疑一切。当调试代码陷入僵局的时候，我的做法通常是简单化，删掉了‰，居然还不奏效，不过发现只读取一个文件的话是正常的，但放两个就不行了，于是还是怀疑文件有问题，又是一通折腾，但发现并不是某个文件有问题，因为乱码的出现好像是随机的，跳动的，捉都捉不到，比如以为是第二个数据文件的问题，于是单独输出第二个数据文件，发现居然是正常的，而本来第一个文件是确认没有问题的，却在和另外一个正常文件组合时出现了问题。。。这都什么事情啊，继续折腾吧，干脆把问题进一步简单化，输出一个最简单的数据文件，发现正常，再加一个同样的文件，依然正常，完全不像前面所说的两个文件同时出现时会引发的问题。到这里，问题其实还是不明朗的。有点聊赖和泄气啊，打开了php的手册，搜索mail函数，注意到两点：1.message参数的说明：Each line should be separated with a LF (\n). Lines should not be larger than 70 characters.  2. 给了一个table 的例子，说明table输出肯定是没有问题的，而且同样是输出一个html，说明我的逻辑没有问题，不过不同的是例子中分行处理了，结合第1点不难发现其实就是一点，采用mail函数发信，其message参数内容的每行长度不要超过70个字符，并且行间以\n分隔，真是太折腾了，而且从问题的表现来看，很难想到会是在这里出现了问题，前面提到的三种可能以及后面的种种怀疑一个都没对，实在有些不该啊。等解决问题，并收拾摊子后，一看时间，午夜2点10分了，赶紧躺下睡觉。

这几天这件事情对我触动还是比较大的，我在想最正确最短路径的调试策略是什么，是不是可以这样来总结呢：

1.出错列出各种可能，像文中开始那样

2.不要急于修改程序及数据文件，而是保留现场，看程序运行到哪里出错的，这样的话其实都可以跳过1中的种种可能而直接怀疑到mail函数头上来。

3.对于自身不可控或者调用程序部分，应该马上查看手册说明或者上网搜索前人的总结。

这样如此一来，程序调试的最短路径便是找到出错的地方（总共代码也就几十行，而且按阶段划分的话，该地方正好是逻辑的衔接点，很好找到），然后查看手册，仔细阅读，哪怕看似熟悉，如果没看过其运行机制，那还是要老老实实的看的。就此是可以发现问题并解决的。

虽然如果不去深究mail函数的运行机制，是不可能找到这个错误的解释的，但作为任务，如果能够以最短路径来解决此问题，效率比实际情况要高不知多少倍。至少自己也不用折腾到那么晚了（leader也在过了0点时一直关注着进度）。写下来分享，愿各位及自己都能更加高效的工作。