From 93cadcc7f135ac2035c2d2058d7aa99453dab149 Mon Sep 17 00:00:00 2001 From: Nanaloveyuki Date: Sun, 14 Jun 2026 11:28:42 +0800 Subject: [PATCH] :memo: clarify logger context field binding --- docs/api/logger-with-context-fields.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/api/logger-with-context-fields.md b/docs/api/logger-with-context-fields.md index c5d55f4..553045f 100644 --- a/docs/api/logger-with-context-fields.md +++ b/docs/api/logger-with-context-fields.md @@ -37,6 +37,7 @@ Detailed rules explaining key parameters and behaviors - Context fields are merged at write time, not by mutating previously created records. - When a log call also passes per-record fields, the context fields are placed before those per-call fields. - This API returns a new typed logger wrapper; it does not mutate the original logger variable. +- The returned logger keeps the same stored target, min level, and timestamp behavior while extending the sink pipeline with context-field merging. - `bind(...)` is an ergonomic alias for this same behavior. ### How to Use @@ -57,6 +58,8 @@ In this example, both `service` and `region` are automatically included on every And callers only need to provide fields that actually vary per event. +The original base logger value is still unchanged if later code keeps using it directly. + #### When Build Child Loggers For Subsystems When a subsystem has both a target and fixed fields: @@ -81,3 +84,5 @@ e.g.: 2. Prefer `fields([("k", "v")])` when you want a more ergonomic call site. +3. Use `bind(...)` when you want the same behavior with a shorter, library-style call name. +