首先，正如@darioo所说：
- MDC用于将多个事件与很少的“实体”相关联
- [标记]用于要从常规事件中过滤掉的“特殊”事件
因此，您断言要为此使用MDC。标记用于突出显示“特殊”事件（如果需要的话），而不是“切片”。例如，您可能基于特定用户进行切片，但根据任何意外异常进行过滤。在这种情况下，您将创建一个
用户 MDC维和一个 UnexpectedException 标记。
但这显然不能解决您所想到的问题。您“更确切地说是指如何更一致地使用标记设置日志记录”。因此，让我们解决：
MDC用于 切片和切块 ，而Mark用于 过滤 。 这些活动在测试和生产过程中进行
。因此，您需要确定在进行测试/生产时，期望使用哪些维度来切片日志数据，以及在哪些情况下对其进行过滤可能有用。 每个维度都有一个MDC维度。
每个案例都有一个标记。就这么简单。
开发人员无需在这里做出任何决定。 一个人或一个团队应该 在设计时
决定需要支持哪种切片，切块和过滤。可以通过想象可能要求他们执行哪种分析任务来告知这一点。
同一个人或团队应决定命名约定。 这完全是任意的 。选择一种在审美上令人愉悦，具有 自我描述性
（最重要）且足够具体的东西，以免与以后的添加冲突。连字符 与
下划线的含义非常模糊，令人震惊，但请注意，ESL员工阅读下划线可能会更加混乱（至少与CamelCase相比）；同时，据报道，由于无法获得必需的密钥，这使某些开发人员感到烦恼。
就决定策略而言，这仅意味着 定义在什么情况下需要使用给定的标记或MDC维度
。保持紧密（集中，故意的），但是如果开发人员认为维度和标记集不足以应付当前任务，则可以征求他们的反馈。适当修改/添加尺寸和/或属性。
了解 此政策几乎必然是针对特定项目的
。并非每个项目都需要相同类型的日志分析。想象一些噩梦场景。然后想象一下您希望如何分析这种情况下的日志。您可能不想编写复杂的脚本来尝试跟踪哪个消息属于哪个上下文，哪个时间是哪个状态，对吗？对尺寸和标记之类的任何必要信息进行编码，如果出了问题，可以省去一些麻烦。
