.NET Microsoft.Extensions.Logging中EventId与名称的选用及最佳实践

一、关于仅设EventId为0的现状 #

• 不少开发者初期确实会忽略EventId，直接设为0，只靠事件名称做日志识别。但这不是推荐做法——EventId的int值在日志聚合、过滤时比字符串名称性能更好，尤其是大规模日志场景。
• 0本身没有特殊的“首选”属性，但不建议全用0：当你需要快速定位某类日志（比如错误事件），统一的0值会失去过滤维度，没法区分不同类型的日志事件。

二、LoggerMessageAttribute 默认值的逻辑 #

• LoggerMessageAttribute.EventId默认值是-1，但这不是“随机值”：代码生成器会基于事件名称（或方法名）的哈希值生成一个相对唯一的int32 ID。这种方式能省掉手动赋值的麻烦，但哈希可能存在极低概率的冲突，且生成的ID没有业务含义，不方便追踪。

三、EventId 管理的最佳实践 #

1. 唯一性范围：类别内唯一即可 #

EventId只需要在**同一日志类别（Logger Category）**内保持唯一。日志类别通常对应你的类名或业务模块，比如OrderService、PaymentProcessor，同一类别内的不同事件用不同ID区分就行，跨类别重复ID不会造成混淆——日志系统会结合类别和EventId一起识别事件。

2. 兼顾易用性与可维护性的方案 #

（1）模块级枚举 + 显式指定

不用搞全局大枚举，按业务模块定义小型枚举就行，比如：

public enum OrderLogEventId
{
    OrderCreated = 100,
    OrderFailed = 101,
    OrderCancelled = 102
}

然后在LoggerMessageAttribute里显式指定：

[LoggerMessage(EventId = (int)OrderLogEventId.OrderCreated, Level = LogLevel.Information, Message = "订单 {OrderId} 已创建")]
public static partial void LogOrderCreated(this ILogger logger, int orderId);

这种方式既保证了ID唯一性，又能通过枚举快速查找事件的使用位置，还和代码生成完美兼容。所谓的“冗余”其实可控——枚举名和方法名对应，反而增强了可读性，比如OrderCreated和LogOrderCreated的关系一目了然。

（2）手动指定有业务含义的ID

如果不想用枚举，可以直接给每个日志事件指定有业务含义的ID，比如订单模块从100开始，支付模块从200开始，这样看到ID就能大致判断所属模块。比如：

[LoggerMessage(EventId = 100, Level = LogLevel.Information, Message = "订单 {OrderId} 已创建")]
public static partial void LogOrderCreated(this ILogger logger, int orderId);

需要注意维护一个文档或注释记录各模块的ID范围，避免冲突。

（3）接受自动生成的ID（适合小型项目）

如果项目规模小，日志事件不多，完全可以依赖代码生成器自动生成的哈希ID。这种方式零维护成本，只要事件名称不重复，哈希冲突的概率极低，足够满足小型场景需求。

3. EventId.Name 和 Id 的选择 #

• 如果你的日志工具更擅长处理字符串（比如按事件名称过滤），可以重点关注EventId.Name（由LoggerMessageAttribute.EventName指定，默认是方法名），此时Id可以用自动生成或设为0，但还是建议保留唯一Id提升性能。
• 对于大规模日志系统，优先保证Id的唯一性：int类型的过滤、聚合性能远高于字符串，且很多监控工具对EventId的int值支持更好，能快速统计不同事件的发生次数。

内容的提问来源于stack exchange，提问作者Philippe