1月22日，自己收到自己公司的产品包装盒三份（自己没下过订单），追查系统日志，最后发现公司内一同事ecstore本地开发环境的订单信息同步到了matrix上，接着matrix又推送到oms系统上。。。和同事确认近半年没有改过本地对联表内一切数据，那么真相只有一个，那就是商派matrix方的代码动过了，修改过验证机制，导致不是授权域名发送到matrix的请求也能正常接收了，这尼玛的真坑啊，这改的人可以扔出去火化了。

事情已经过去，期间追查系统时，由于需要查看日志，所以看了一遍日志模块的源码，顺便记录下来。

1.日志类文件路径在/base/lib/static/logger.php
2.一开始怀疑是创建订单时数据意外回滚了，所以追查了db方面的代码，精确到/base/lib/db/connections.php中的exec方法，这是所有sql执行调用的方法，包含回滚事务。该方法最后代码如下，

if($rs = mysql_query($sql,$db_lnk)){
   self::$mysql_query_executions++;
   logger::debug('sql:'.self::$mysql_query_executions.'.'.$sql);
   $db_result = array('rs'=>$rs,'sql'=>$sql);
   return $db_result;
}else{
   logger::error($sql.':'.mysql_error($db_lnk));
   trigger_error($sql.':'.mysql_error($db_lnk),E_USER_WARNING);
   return false;
}

无论执行结果如何，都调用了logger的方法，虽然事后原因根本和logger无关，但这里还是具体看了一下。
3.logger类中的log方法首先判定了当前系统的默认日志级别，如没有在config中额外配置的话，应该是’info’级别，所以上面代码中成功部分的logger::debug是不会显示在日志文件里的，除非有必要调试，否则没有必要开始debug模式，这样会造成大量的I/O，后果很严重。
紧接着通过下面代码生成日志格式。

if(defined('LOG_FILE')){
   $logfile = str_replace('{date}', date("Ymd"), LOG_FILE);
   $ip = ($_SERVER['REMOTE_ADDR']) ? $_SERVER['REMOTE_ADDR'] : '127.0.0.1';
   $ip = str_replace(array('.', ':'), array('_', '_'), $ip);
   $logfile = str_replace('{ip}', $ip, $logfile);
}else{
   $logfile = DATA_DIR . '/logs/all.php';
}

4.确认一下config里是否开启了以下定义：

// 按日期分目录，每个ip一个日志文件。扩展名是php防止下载。
define('LOG_FILE', DATA_DIR.'/logs/site/{date}/{ip}.php');

如果有的话，那么log文件会以IP的形式存放在已当前日期为文件夹的路径下。

以上，是所有ecstore默认的logger类的工作原理，over!