Serilog中命名占位符为何不能为数值？结构化日志优势解析

1. 为何Serilog使用{0}、{1}数值占位符会触发警告，Console.WriteLine却不会？ #

Serilog的{ }语法本质是结构化日志的属性占位符，并非传统的位置替换标记。当你写{0}、{1}时，Serilog会将这些数值当作日志事件的属性名称，但数值属性名完全不符合结构化日志的设计初衷——结构化日志依赖有语义的属性名实现高效的日志过滤、查询和分析，数值名无法直观表达对应数据的含义，因此Serilog的代码分析工具（如Serilog Analyzer）会触发「named placeholders should not be numeric values」警告，提醒你使用有实际意义的属性名。

而Console.WriteLine里的{0}是.NET基础类库的位置格式化占位符，仅负责按顺序将参数替换为字符串，不涉及结构化数据的存储与处理，所以不会产生任何警告。

示例代码 #

触发警告的Serilog代码：

_log.LogInformation("some data - {0} and data2: {1} ", data1, data2);

正常运行的Serilog代码：

_log.LogInformation("some data - {data1} and data2: {data2} ", data1, data2);

无警告的Console.WriteLine代码：

Console.WriteLine("some data - {0} and data2: {1} ", data1, data2);

2. Serilog结构化日志相比字符串插值有哪些优势？ #

• 保留原始数据类型：字符串插值会把所有数据强制转为字符串，结构化日志则保留数据的原始类型（比如整数、布尔值、复杂对象），后续查询时可以直接基于类型做条件筛选（例如查找OrderAmount > 1000的日志）。
• 高效的日志查询与分析：结构化日志的属性会被日志系统（如Seq、Elasticsearch）建立索引，能快速通过属性值精准筛选日志；而字符串插值的结果是纯文本，只能依赖模糊搜索，效率低且容易出现误匹配。
• 避免格式混乱与风险：字符串插值需要手动处理特殊字符，容易出现日志格式错乱；结构化日志由Serilog自动处理格式，同时能避免潜在的日志注入问题。
• 灵活的输出适配：结构化日志可以根据输出目标切换格式——比如控制台输出易读的文本格式，文件存储则用JSON格式；字符串插值的结果是固定文本，无法后期转换格式。
• 便捷的日志增强：可以轻松给所有日志添加全局属性（如请求ID、用户ID），这些属性会自动附加到每一条结构化日志事件中；而字符串插值需要手动拼接这些信息，不仅繁琐还容易遗漏。

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