Azure WebJobs：Console.WriteLine与logger.WriteLine的区别及logger参数意义
这个问题问到点子上了！很多刚开始用Azure WebJob的开发者都会疑惑这俩输出为啥看起来效果一样，但实际上它们在设计意图和实际使用场景上有不小的区别，我来给你详细拆解：
一、Console.WriteLine和logger.WriteLine的核心区别
虽然表面上两者都会输出到控制台和日志文件，但底层逻辑和附加价值完全不同：
日志上下文与可追溯性
logger.WriteLine是WebJob SDK原生提供的日志方式，它会自动携带WebJob的上下文元数据——比如当前作业的名称、执行ID、触发源（队列消息ID、定时器触发时间）等信息。当你在Azure Portal查看WebJob日志或者后续排查问题时，这些元数据能帮你快速定位到具体的作业实例和触发事件。而Console.WriteLine只是系统级的控制台输出，仅会记录纯文本内容，没有任何上下文关联，排查复杂问题时会非常头疼。日志级别与过滤能力
目前你看到的都是"INFO"级别的记录，但logger其实支持多级别日志（Debug、Info、Warning、Error等），你可以通过代码或者配置来控制不同级别日志的输出行为（比如只记录Warning及以上到文件，Debug级只在本地调试时输出）。而Console.WriteLine没有级别区分，所有输出都会被WebJob当作INFO级别处理，后续无法灵活过滤不同重要程度的日志。输出扩展性
logger基于TextWriter抽象，WebJob SDK默认将其输出到控制台和日志文件，但你可以轻松扩展它的输出目标——比如集成Azure Monitor、Application Insights，或者自定义日志存储服务，只需要替换TextWriter的实现即可。而Console.WriteLine依赖系统控制台的输出重定向，扩展性极差，很难对接专业的日志服务。生命周期可靠性
logger和WebJob的生命周期深度绑定，当作业停止、出错或者异步执行时，它会确保日志被正确flush和持久化，不会因为进程意外退出丢失日志。而Console.WriteLine的输出依赖系统缓冲区，在某些异步场景或者进程异常终止时，可能会有部分日志来不及写入文件就丢失了。
二、设置TextWriter logger作为参数的意义
WebJob SDK将TextWriter logger作为触发方法的参数，主要是为了实现以下几个设计目标：
解耦与可测试性
用抽象的TextWriter而不是直接依赖Console，让你的作业方法和具体的输出实现解耦。比如在单元测试时，你可以传入一个StringWriter来捕获日志内容，而不需要依赖真实的控制台输出，大大降低了测试的复杂度。统一日志体系
通过logger，你的自定义日志会和WebJob SDK本身的系统日志（比如队列消息的接收/处理日志、作业启动/停止日志、异常日志）整合到同一个输出渠道，让整个作业的日志体系更统一，便于集中查看和管理。官方规范与兼容性
这是WebJob SDK官方推荐的日志方式，所有触发类型（QueueTrigger、TimerTrigger等）都支持注入TextWriter。使用它能确保你的日志被SDK正确捕获和处理，比如在Azure Portal的WebJob日志页面可以完整看到所有logger输出的内容，而Console.WriteLine在某些复杂场景（比如后台线程的输出）下可能无法被SDK完全捕获。
举个简单的代码对比例子：
public static void ProcessQueueMessage([QueueTrigger("order-queue")] Order order, TextWriter logger) { // 使用logger的日志，会携带作业上下文 logger.WriteLine($"Processing order: {order.Id} | Triggered at: {DateTime.UtcNow}"); // Console输出，仅纯文本 Console.WriteLine("Order processing started"); }
查看日志时，logger的输出会类似：
[INFO] [2024-05-20T10:30:00Z] [JobHost] Processing order: 123 | Triggered at: 2024-05-20T10:30:00Z
而Console的输出则是：
[INFO] Order processing started
显然前者的可追溯性要强得多。
内容的提问来源于stack exchange，提问作者Oleg Sh
