说了不要日志，我却打得满天飞，这是拼命打自己脸

她来了，她来了，她带着甜美的笑容走过来了。

是的，我没看错，她笑颜如花，冲了一杯咖啡像我走过来。

她：“给，这是办公室钥匙，我喝完咖啡就走了。”

是呢，我在想什么呢，其实我啥都没在想，就只是在看日志。

我呢，前面有说过，我因为Python项目看着漫天的日志，重做了优化，给它删除了一大半的日志处理功能，后来日志就清晰了很多，但实际上，还是有很多地方有日志的。

优化的地方大部分都是一些无关的逻辑打印，以及那种线程里面不断滚动的垃圾内容。

有了编译器，我们就能够很好的把整体逻辑都在自己的把握下完成了百分之五十（别在意这个预估值，我乱邹），总之基础逻辑该调的改写的，在IDE的处理下，我们基本都能够很好的完成这些工作，如果完不成，那就加班去做吧。

但是呢，我们会默认的忍不住要嘛不想去打日志，要嘛就是每个都打日志，实际上要不要打这个得靠个人经验，该打哪些也得靠个人经验，因为逻辑是你写的，逻辑校验需要你去处理，什么是关键节点，又要打些什么内容，这个得你自己决定。

我是以案例出发的思维来说，肯定不符合你的实际

第一，考虑的问题是日志要不要写数据库？为什么写数据库？

我基本不会太考虑写数据库，基于数据库的性能和空间问题，大部分的日志记录在数据库是没多大用处，当然除了有金额交易的业务需求除外，一旦涉及到金额交易，不出问题还好，除了问题，谁都逃不掉，就得查，数据库只是相对的，好快速查询和整理一些说明材料而已，其实本地日志也一样，我觉得区别还真没那么大，当然数据库方式总归是比较好些。

还有一个场景，就是网站的一些异常也偏好的记录于数据库，大体都是采用注入的方式捕获了异常，网站的某些后台异常通常能够快速反应在前端，前端主要是客户操作，异常界面看客户心情，浏览器关闭只是瞬间，客户的反馈说法太过模糊，可能圆的都能说成扁的，只有日志能够准确的记录具体原因，而不是客户的那张嘴表达出来的意思。

第二，怎么写方法

对于文件写入，无非就是FileStream的Write方法，但这种方式都得自己实现，如果你是没接触过其他的，可以尝试自己写，但这里还是建议从实际出发，老老实实用Log4Net来，当然第一次配置可能有点摸不着头绪。

我得给你说说为什么，FileStream我们可能用到的地方不会少，比如文件存储，图片保存之类的，或者文件读取，但自己写很容易产生一些问题，就是文件占用问题，所以应用的时候经常还得考虑文件权限，文件锁之类的，总之你用了自己的方法，那就只能自己解决，我没啥能多说的。

相对的如果用的是Log4Net稳定性来讲，配置是问题，打印的内容都会偏多，当然这个通过配置也可以去掉，但整体来说，就好比你买手机，你是愿意买性价比高的，还是自己造的，毕竟人家是专业的，而你还不是，这就是区别。

第三，打哪些内容

这个也是重点，来，拿笔记。

通常我的出发点肯定是什么都打就好，但论实际场景来讲，肯定要有自己的考量了。

硬件业务，这个日志内容一般会比较多，比如硬件的协议数据，我估计你肯定一开始都会记录的吧，那一大串，有长又臭的编码，打了感觉毫无用处，不打又天天担心，网络是不是掉包，造成某些数据包问题，而产生的程序异常。这点讲，其实做个开关就好了，而且是那种随手可以点一下的按钮来控制，日志是否写入就行了，不用太纠结，在项目之初逻辑上都处理完毕，你打过的日志，基本能够保证硬件对接协议报文的出错率应该很低，如果出错率高，比如一万次就有一次错误，我建议你跟经理老实讲，这个硬件这个型号直接退还给厂家，一辈子都不要再让你见到。这种硬件拿一个砸一个。

日志开关的处理就是，当真的程序产生异常，而且是频繁异常的时候，打开后来排查，再具体看看是你逻辑问题，还是真数据包问题，当然通常都是你逻辑问题，这个数据包只是辅助你有一个现场环境的日志让你完善逻辑而已。

而且硬件业务的处理主要以线程方式，有于跟踪，硬件设备的稳定性，这里的硬件设备稳定性不是那种简单的定义，数据包接收问题，而是环境产生问题（比如实验环境都是单模块，单电源测试的，而现场乃是十几套甚至几十套奇怪设备堆砌在一起玩层层乐的那种，电压稳定，线路干扰都会有影响）。线性的日志就能够很好的记录，硬件节点和处理环节是否存在一些难以在开发阶段的问题。

软件业务，基本都是和数据库相关，这个也得打，诶，不是让你自己存数据库啊。数据库本身异常，你打给谁，那个叫记录异常，别曲解了。

数据库相关的，只的是记录所有与数据库交互的相关处理。

数据库SQLHelper你肯定会封装一些方法，比如

DataTable GetDataTable(String Sql)
{
    log4net.log(Sql);
    //业务
}

int InsertSQL(string Sql);
{
    log4net.log(Sql);
    //业务
}

之类的的方法，就把，日志方法处理进去，Log4Net可以配置单独的文件类记录这些，如下面所示，当然具体你得自己去，给你升级地点，自己打怪这很正常吧。

可能你没想过，打这些查询日志基于什么目的，来，让我告诉你

---

我们做个假设场景，通常都是真实存在的，某一天，小明在吃饭，突然接到电话，说平台有一天的没收到上传，小明很委屈，项目都交出去半年了，而且你平台关我鸟事，我压根就没听过，你还找我做鸟？

但接着老板也是一通电话：“赶紧解决问题去”，可能你连饭都吃这不香了。

结果排查xx年xx月xx日0点，数据库已经崩溃，全天数据库未存储，业务逻辑乱七八糟，你是不是很想骂，他爷爷的熊孩子怎么能这样，数据库一整天没上传，就因为数据库密码过期访问不了，一整天啊，不是一分钟啊，都没人发现吗？

但事还是得你来解决，除非，你现在不跟老板拿工资了，所以你会敲你自己的头，为什么当时就不备份一套能够直接批量处理的插入日志日志呢？

这样就可以来一句：“妈蛋，丢了哪些业务逻辑日志，自己把日志拿过去批量执行就好了，别烦我，我再吃包子！！！，对，日志放那个目录了我不知道，文件叫什么我也忘了，你自己找，对，我私房钱都藏在床底！整整三十九块，哦，No……”

---

<log4net>
    <!-- OFF, FATAL, ERROR, WARN, INFO, DEBUG, ALL -->
    <!-- Set root logger level to ERROR and its appenders -->
    <root>
      <level value="ALL" />
      <appender-ref ref="SysAppender" />
      <appender-ref ref="SQLRollingFileAppender" />
      <appender-ref ref="InfoRollingFileAppender" />
      <appender-ref ref="ErrorRollingFileAppender" />
      <appender-ref ref="FATALRollingFileAppender" />
    </root>

部署环境排查问题，总或多或少需要用到排查这些语句的问题，甚至包括查询的条目，查询的参数等，都用打到日志，然后自行编写一个日志分析格式的小程序，快速将日志+参数转成普通的查询语句，这么做的目的，还不是为了，如果项目移交过后，你该干嘛就干嘛，有问题找维护人员搞，别来烦我。至于分析转化怎么写，那得问你自己，爱怎么写就怎么写，我管不着，也不想管。

除了数据库日志，还有就是业务逻辑日志，通常主界面都会编写一个日志写入用ListBox就行比如这样

        public delegate void ShowMessage(string mess, bool blnLog,bool blnClear);
        /// <summary>
        /// 委托方法 显示日志内容
        /// </summary>
        /// <param name="mess">消息</param>
        /// <param name="blnLog">是否保存到Log4net文件</param>
        /// <param name="blnClear">是否清除listbox日志</param>
        public void ShowListBoxMessage(string mess, bool blnLog = true,bool blnClear=false)
        {

            try
            {
                //判断一下新线程来访问listbox1这个控件的listBox1.InvokeRequired属性是true还是false;如果是其他的线程来访问自己的线程，则返回值是ture
                if (listBox1.InvokeRequired)
                {
                    //因为是其他的线程来访问自己的线程，所以返回值是true，既然是其他的线程来访问，为了安全，必须转回到自己的线程，这就用到了委托
                    ShowMessage s = new ShowMessage(ShowListBoxMessage);//将showMess函数变成新造的线程能够调用的
                    this.Invoke(s, mess, blnLog, blnClear);//在拥有Listbox控件的窗体上执行这个委托
                }
                else
                {
                    if (blnClear)
                    {
                        listBox1.Items.Clear();
                    }
                    DateTime dtMsg = DateTime.Now;
                    mess = dtMsg.ToString() + "      " + mess;
                    listBox1.Items.Insert(0, mess);
                    if (blnLog)
                    {
                        lognet.LogInfo(mess);
                    }
                }
            }
            catch (Exception ex)
            {
                lognet.LogError(ex);
                listBox1.Items.Insert(0, "listbox异常了" + ex.Message);
            }
        }

这样即能快速的在排查过程看到对应日志，也能很好的记录这些逻辑和异常，如果这样你心里基本前期是比较有底了。

能够打在界面的东西尽量都打，尤其是某些业务，能打就打，反正每天自行存一个文件，日志再多也就几兆，通常我建议用软件UltraEdit 这个可以打开被占用文件，和刷新正在写入的内容，自己研究相对还是比较好用的。

 

说到这里，其余的就不多讲了，可能再给两天也讲不玩，日志如何玩，总之，经验得你自己总结，这里没有高深到让你觉得炫酷的技巧，有的只是从自身过程中让开发人员能够自行思考的入门而已。