1. 先别急着改代码配置文件这关过了吗我见过太多人排查 Log4Net 不输出日志上来就翻代码什么logger.Info(test)写没写、logger有没有初始化折腾半天毫无进展。实际上Log4Net 不输出日志十有七八是配置环节出了问题而且问题远比你想象的隐蔽。先说一个最经典、杀伤力最大的坑配置文件根本没被加载。Log4Net 不是靠魔法工作的它必须有一个配置来源要么是独立的 XML 文件要么是程序的App.config/Web.config。很多新手在项目里添加了log4net.config文件认认真真写好了 appender然后发现日志死活不出来。为什么因为代码里压根没有告诉 Log4Net “去读这个配置文件”。如果你用的是独立配置文件比如log4net.config必须在代码入口处加一行[assembly: log4net.Config.XmlConfigurator(ConfigFile log4net.config, Watch true)]或者放在Main方法里手动加载var logCfg new FileInfo(AppDomain.CurrentDomain.BaseDirectory log4net.config); log4net.Config.XmlConfigurator.Configure(logCfg);这里有个关键细节ConfigFile指定的路径是相对路径最终会解析到应用程序的基目录BaseDirectory。控制台程序和 WinForms 程序基目录通常就是bin\Debug或bin\Release。如果log4net.config文件在项目根目录但生成后没有复制到输出目录那么运行时根本找不到这个文件日志自然一条都不会输出。配套的问题是“是否复制到输出目录”。在 Visual Studio 里选中log4net.config看属性面板复制到输出目录必须设置为始终复制或如果较新则复制。这一步漏掉配置等于不存在。我碰到过一个项目开发机上能输出日志换一台机器部署后死活没有最后发现就是因为 SVN 拉下来的代码里log4net.config的“复制”属性没带上去新签出的工程文件直接丢失了这个设置。再补充一个容易被忽略的点如果你在AssemblyInfo.cs里用了XmlConfigurator特性但配置文件的名字写错了Log4Net 会静默失败还是抛异常答案是默认不抛异常只写内部错误日志。而内部错误日志默认又是关闭的所以一切看起来毫无征兆。这个我们后面会专门讲怎么打开 Log4Net 的内部调试开关那是定位这类问题的终极武器。还有人在App.config里写好了配置但忘了往log4net节点外面包configSections。这是又一个高频问题configuration configSections section namelog4net typelog4net.Config.Log4NetConfigurationSectionHandler, log4net/ /configSections log4net ... /log4net /configurationconfigSections必须在configuration下的第一位置前面不能有任何其他节点。如果你把log4net写在configSections前面或者忘了声明 sectionLog4Net 就读不到配置。VS 不会报错编译不会报错运行时也不会有任何提示一切照常“沉默”。2. 日志级别和继承机制为什么“明明调用了 Info却什么都没有”配置文件没问题、文件也确实加载了日志还是不输出那就要往 Log4Net 的内部机制上看了。我经常用一个比喻Log4Net 的日志记录过程就像公司内部的文件审批流程。你写了一个请求日志事件递交给某个部门Logger但这个部门有没有权限处理要看它的“级别”够不够。而且部门之间还有上下级关系上级定了规矩下级默认照办。Log4Net 里每一个 Logger 都有名字通常我们按命名空间来创建private static readonly ILog log LogManager.GetLogger(typeof(Program));这里的 Logger 名字一般就是namespace.ClassName比如MyApp.Program。Log4Net 的 Logger 之间存在着层级继承关系MyApp.Program的父级是MyApp再往上是根 Loggerroot。配置里通常会有这样的内容root level valueDEBUG / appender-ref refRollingFileAppender / /rootroot 就是层级的最顶端所有 Logger 最终都会继承它的设置。如果你在配置里给某个特定 namespace 设置了 level比如logger nameMyApp level valueERROR / /logger那么MyApp这个命名空间下的所有 Logger包括MyApp.Program默认都会继承ERROR级别。注意这个“继承”有多坑——你日志调用写的log.Info(xxx)级别是 INFO而当前 Logger 的有效级别是 ERRORINFO 低于 ERROR事件被直接丢弃连 appender 的门都进不去。这个问题的隐蔽性在于不是你的代码错了也不是配置没加载而是日志级别过滤器把事情拦住了。再看一个具体案例。有个朋友做的 WinForms 项目界面操作半天日志文件里只有零星的几行 ERROR 级别记录所有 INFO 和 DEBUG 内容全没有。他贴出配置让我看root里 level 明明写的DEBUG。我让他把正在使用的 Logger 名字完整打印出来结果发现他在某个类里用的是LogManager.GetLogger(MyApp.DataAccess)看起来好像没问题但实际他的配置里写了logger nameMyApp.DataAccess level valueWARN / /logger这个配置是当年做性能优化时加的说是业务日志不重要WARN 以下不要。结果半年后团队里新同事接手在DataAccess命名空间下新写了一个类想记录 SQL 执行详情INFO 全被吞了查了两天。所以排查的时候第一步永远是搞清楚当前 Logger 的名字到底是什么、它的有效级别是多少。直接在代码里临时输出Console.WriteLine(log.Logger.Name); Console.WriteLine(((log4net.Repository.Hierarchy.Logger)log.Logger).Level);如果Level为 null说明没有显式设置继承父级如果显示的是某个你没想到的值那配置里八成有“隐形”的logger节点在作怪。另外一个跟继承相关的坑Appender 的继承。你给 root 配了RollingFileAppender按理说所有 Logger 都会往这个文件里写。但如果你在某一个logger节点里自己加了appender-ref而不加additivityfalse日志会同时往两个地方写。反之如果你加了additivityfalse那这个 Logger 就只用自己的 appenderroot 的 appender 对它无效。有人以为 root 里配了文件 appender就万事大吉结果某个模块的日志就是没有一查原来那个 Logger 节点里写了个additivityfalse而且没配任何 appender——日志到达这个 Logger 之后既不往上传递自己又没处写直接人间蒸发。3. 常见项目类型里的典型坑位控制台、WinForms、ASP.NET 各有各的坑不同项目类型Log4Net 出问题的侧重点完全不一样。我按项目类型把踩过的坑归一下类你在排查的时候可以直接对照自己的环境。3.1 控制台程序和 Windows 服务控制台程序是 Log4Net 的“重灾区”因为很多人从控制台程序开始学但对程序入口生命周期理解不够。控制台程序最常见的坑是配置加载的时机晚于第一次日志调用。比如你在Main里这样做static void Main(string[] args) { // 某个静态类在初始化时会打日志 var helper new Helper(); helper.DoWork(); // 之后才配置 Log4Net XmlConfigurator.Configure(); }静态类在初始化时如果已经尝试写日志而此时 Log4Net 还没 Configure所有日志事件都会被丢弃。更麻烦的是Helper类的static readonly ILog log LogManager.GetLogger(...)在类加载时执行但GetLogger不是问题真正的日志写入在Configure()之前发生才是问题。Windows 服务还有一个特殊坑工作目录不等于程序集所在目录。服务的当前目录经常是C:\Windows\System32如果你用相对路径配置日志文件比如file valuelogs\\app.log /那日志文件可能出现在C:\Windows\System32\logs\app.log下面你找半天找不到。而如果用%ProgramData%这类环境变量做路径又要额外去检验系统账户的写权限。Windows 服务的经典排错永动机文件没生成就去看是不是权限问题权限没问题再看是不是路径被重定向了路径没问题再看是不是日志被系统服务账户写到了别处。3.2 WinForms 和 WPFWinForms 和 WPF 项目里Log4Net 配置文件通常放在App.config里运行时被编译为exe.config。这里有一个隐蔽的坑你在项目里看到了 App.config改了里面的 log4net 配置然后直接 F5 调试发现日志行为没有变化。原因Visual Studio 调试时使用的是bin\Debug\xxx.exe.config它是由 App.config 在编译时生成的。如果你改了 App.config重新编译后确实会同步到输出目录。但如果你手贱改了输出目录里的那个 config 文件来调试然后又一次编译覆盖两种状态就存在差异了。说白了一定要记住“改源代码里的 App.config别改动输出目录的临时产物”。WPF 项目还有一个常见问题使用了 NuGet 包Microsoft.Extensions.Logging.Log4Net.AspNetCore或log4net搭配 DI 容器。如果你看到有人的 WPF 项目里日志时有时无先去看看IServiceCollection里日志的配置是否和 app.config 里的log4net配置冲突。尤其是当你用AddLog4Net()扩展方法时它默认会把log4net的 repository 从默认的配置来源里重设一遍这在多配置源环境下很容易覆盖你的手动配置。3.3 ASP.NET / Web 项目ASP.NET传统 Framework下Log4Net 的配置写在Web.config里。这里有两个高频问题第一个是权限。IIS 应用程序池默认账户是IIS AppPool\xxx它对磁盘的写入权限是受限的。如果日志文件夹放在网站根目录下程序池账户没有“写”权限Log4Net 会在写文件时抛异常。这个异常通常不会冒到页面上而是被 Log4Net 吞掉表现症状依然是“没日志”。第二个是应用池回收导致日志文件被占用。滚动文件 appenderRollingFileAppender会长时间锁定日志文件句柄。应用池回收时如果文件没有正确释放可能导致新进程无法写入表现为日志突然中断重启站点后恢复。严格来说这不是不输出的问题但表现得非常像“不输出”。appender nameRollingFileAppender typelog4net.Appender.RollingFileAppender lockingModel typelog4net.Appender.FileAppenderMinimalLock / /appender加上MinimalLock可以在每次写日志时获取和释放文件锁牺牲一点性能换来文件不被长期占用。对 Web 项目来说这个取舍通常值得。3.4 .NET Core / .NET 5 项目.NET Core 和 .NET 5 对 Log4Net 的配置方式不完全一样。这里最大的坑是传统[assembly: XmlConfigurator]特性在 .NET Core 下依然有效但如果项目文件csproj里没有把配置文件标记为CopyToOutput配置一样读不到。.NET Core 项目默认会有一个appsettings.json很多人习惯性地把所有配置塞进去但 Log4Net 默认不认它还是只认log4net.config或App.config里的log4net节点。如果你非要用appsettings.json来配 Log4Net需要额外引用Microsoft.Extensions.Logging.Log4Net.AspNetCore包并且调用AddLog4Net()再通过配置系统绑定链路复杂且更容易出错。还有一点.NET Core 3.0 内置了Microsoft.Extensions.Logging如果你在CreateHostBuilder里调用了ConfigureLogging并且同时使用了 Log4Net 的 provider那么日志事件会经过两套过滤系统。第一套是Microsoft.Extensions.Logging的日志级别过滤默认LogLevel.Information第二套才是 Log4Net 自身的 level。你 Log4Net 里配了 DEBUG但宿主配置里LogLevel是 Warning那 Debug 级别的日志照样被外面那层挡掉。很多人忽略这层“双重过滤”排查半天以为是 Log4Net 的问题。4. 仓库冲突、自定义 Appender 和异步陷阱过了基础配置和级别过滤这些坎之后还有一类问题比较高级但一旦遇到没有经验的人会卡很久。4.1 多个 Repository 导致的“双重沉默”Log4Net 支持创建多个仓库Repository。默认情况下所有程序集共享同一个log4net.Repository.ILoggerRepository也就是LogManager.GetRepository()返回的默认仓库。但有些场景下你的项目引用了一个第三方库这个库自己也带了 Log4Net而且它可能创建了独立的 repository。仓库之间是隔离的。如果你在程序里通过LogManager.CreateRepository(MyRepo)创建了一个自定义仓库然后用LogManager.GetLogger(MyRepo, MyClass)去取 Logger但配置却通过XmlConfigurator.Configure()加载到默认仓库里——两边各说各话那就完全对不上号。具体症状配置没问题、代码没问题但日志就是不输出。排查手段是在代码里打印当前 Logger 所属的 repositoryvar logger LogManager.GetLogger(typeof(Program)); Console.WriteLine(logger.Logger.Repository.Name); Console.WriteLine(logger.Logger.Repository.Configured);看Configured是否为 true如果为 false说明这个仓库压根没有被配置文件初始化过。还有个典型场景是单元测试和主程序交替运行的“仓库混乱”。测试框架比如 NUnit在测试程序集里加载 Log4Net测试程序集和被测程序集可能各自带[assembly: XmlConfigurator]导致两个仓库都初始化但互不认账。最后测试输出里没有日志不是真的没有是日志写到“另一个仓库”的 appender 里去了。4.2 自定义 Appender 的初始化失败有时候你会写一个自定义 Appender继承AppenderSkeleton想要把日志写到Console之外的某个地方比如数据库、消息队列、自研的存储。自定义 Appender 写好后在配置文件里引用appender nameCustomAppender typeMyNamespace.MyCustomAppender, MyAssembly threshold valueINFO / /appender运行后日志一条都没有。你以为配置没生效其实很有可能自定义 Appender 的构造函数或ActivateOptions()方法抛了异常。Log4Net 的机制是创建 Appender 时如果发生异常默认只是记录内部错误不向外抛。所以自定义 Appender 上线前务必要在ActivateOptions()里做好异常处理把异常打出来public override void ActivateOptions() { base.ActivateOptions(); try { // 初始化资源 } catch (Exception ex) { // 输出到控制台或 Windows 事件日志 Console.Error.WriteLine(CustomAppender init failed: ex); throw; } }抛出异常至少能让问题暴露出来。如果你保持静默失败这个 Appender 会“假装自己很好”但 append 方法永远不会被调用。4.3 异步 Appender 的缓冲丢失AsyncAppender是 Log4Net 的异步包装器它先把日志事件放进内存队列后台线程再写入内部真正的 appender如文件。用完之后如果程序直接退出控制台Main结束或者Environment.Exit队列里缓存的事件可能来不及写入文件表现为日志文件缺失或内容不完整。解决方案是在程序退出前显式清理LogManager.Shutdown();Shutdown()会遍历当前仓库里所有 appender调用它们的Close()方法异步 appender 会在关闭前尝试把队列里的剩余事件处理完。有人写控制台工具日志偶尔丢几条就是因为异步 appender 没做这一步。WinForms 程序可以在Application.ApplicationExit事件里调用WPF 可以用Dispatcher的Application.Current.ExitASP.NET 可以在Application_End里做。5. 终极武器让 Log4Net 自己把错误说出来前面说的那些问题核心难点都在于 Log4Net 默认的“静默失败”配置文件加载失败不吭声、Appender 初始化失败不吭声、级别过滤丢弃事件不吭声。所以排查到最后绕不开一个东西——Log4Net 的内部诊断日志。在配置文件里加上以下内容appSettings add keylog4net.Internal.Debug valuetrue / /appSettings或者直接在代码里设置log4net.Util.LogLog.InternalDebugging true;开启之后Log4Net 的内部错误信息会输出到控制台或者系统事件日志取决于宿主环境。这些信息包含配置文件的加载结果成功还是失败每个 appender 的创建过程配置节点解析时遇到的错误调用Configure()时具体的异常信息。我第一次用这个开关排查问题时就看到了类似这样的输出log4net:ERROR Failed to find configuration section log4net in the applications .config file.那一刻才恍然大悟——原来配置文件压根没被识别为有效的 Log4Net 配置因为configSections里没有声明log4net节点。这个错误在不开Internal.Debug的情况下是完全隐形的。除了内部调试日志还有一个“探测性”手段值得掌握在代码用log4net.LogManager.GetRepository()拿到仓库后手动遍历所有 appender并检查其状态。var repo log4net.LogManager.GetRepository(); foreach (var appender in repo.GetAppenders()) { Console.WriteLine($Appender: {appender.Name}, Type: {appender.GetType().FullName}); }如果你看到仓库里的 Appender 列表是空的说明配置文件没有被正确加载。如果列表里有 Appender但日志还是不输出那就要进一步结合前面说的级别过滤机制判断。再来说个很有用的排查技巧给同一个配置文件临时加一个 ConsoleAppender级别设到最低。appender nameConsoleAppender typelog4net.Appender.ConsoleAppender layout typelog4net.Layout.PatternLayout conversionPattern value%date [%thread] %-5level %logger - %message%newline / /layout /appender root level valueDEBUG / appender-ref refConsoleAppender / appender-ref refRollingFileAppender / /root这样日志既写文件也打印到控制台。如果控制台能看到日志但文件里没有那就是文件 Appender 的问题路径、权限、锁定模型如果控制台和文件都没有那就是更上游的问题配置加载、Logger 级别、日志调用。这个“二分法”能快速把问题域缩小一半。6. 一手经验总结从“零日志”到“日志正常”的排查顺序最后我把自己实际排查 Log4Net 不输出日志问题的顺序整理一下。按这个顺序走一遍大概率能在半小时内定位问题。确认配置文件存在且被加载独立配置文件有没有复制到输出目录用的是App.config还是独立文件入口处有没有XmlConfigurator.Configure()或[assembly: XmlConfigurator]特性。确认配置文件格式合法configSections是否声明了log4netsection如果放在 app.config 里XML 本身是否良构appender 类型名是否正确程序集名有没有写全。开启内部调试日志设置log4net.Internal.Debugtrue查看输出寻找ERROR或Failed关键字。确认 Logger 级别打印当前 Logger 的名字和有效级别检查是否有父级logger配置覆盖了 root 的级别检查 root 的level是否设置得过高比如ERROR会吞掉所有 INFO/DEBUG 日志。确认 Appender 是否真正被使用用repo.GetAppenders()列出所有已注册的 appender检查对应 appender 是否在 root 或当前 Logger 的appender-ref里被引用如果用了additivityfalse确认当前 Logger 有自己的 appender。最后排查环境性问题文件路径权限异步 appender 的缓冲丢数据仓库冲突、多程序集各自初始化导致的隔离日志文件被进程占用或文件句柄未释放。这套顺序基本覆盖了从“配置读取”到“事件写出”的整条链路。跑一遍之后还找不到原因的情况我印象里几乎没遇到过——如果有绝大多数都能靠着Internal.Debug的输出找到具体异常位置。关于 Log4Net再分享一个小偏方做一个最小可复现样例。在排查陷入僵局时新建一个什么都不做的控制台项目只引入 Log4Net写最简单的一份配置看能不能输出日志。如果最小样例能输出说明问题在你的项目环境里如果最小样例也不能输出说明你的 Log4Net 包或运行时环境有问题直接重装 NuGet 包、清理 bin/obj 目录再试。这个“归零再出发”的思路解决了很多纠结于细节却忘了基础环境的问题的人。日志这东西平时一个人安静地躺着出问题的时候能急死人。但只要把链路拆开、逐段验证它其实比大部分业务 bug 都好排除。希望这篇经验能帮你在下次遇到 Log4Net 不输出日志时少走几步弯路。