log.NewStdLogger(os.Stdout)是最轻量的日志起点，适合开发调试，但无级别过滤和文件切割；替换Zap需用lumberjack实现轮转，并注意AddCallerSkip(2)和配置加载顺序。
用 log.NewStdLogger 快速启用标准输出日志
不改任何配置、不引入第三方库，也能立刻看到日志——log.NewStdLogger(os.Stdout) 是最轻量的起点。它直接把日志写到终端，适合本地开发或调试阶段快速验证逻辑是否触发。
注意两点：
• 它不支持日志级别过滤（比如只显示 Warn 以上），所有 Info/Warn/Error 都会输出；
• 没有文件切割、异步写入等生产特性，上线前必须替换。
典型用法：
logger := log.NewStdLogger(os.Stdout)
h := log.NewHelper(logger)
h.Info("服务启动完成")
替换为 zap 并启用文件切割需手动实现 WriteSyncer
Kratos 的 log.Logger 接口是抽象的，Zap 不能直接传入，必须包装成符合接口的实例。关键在 WriteSyncer：Zap 自身不带轮转能力，得靠 lumberjack 构建可切割的写入器。
常见错误是直接用 os.OpenFile 创建文件句柄，导致进程退出后日志丢失，或并发写入时 panic。正确做法是：
- 用
&lumberjack.Logger封装路径、大小、备份数等参数 - 再用
zapcore.AddSync()转成zapcore.WriteSyncer - 最后传给
zap.NewCore()构造器
别漏掉 zap.AddCallerSkip(2)，否则日志里的 caller 会指向 Kratos 内部封装层，而不是你业务代码的真实行号。
log.With() 绑定全局字段比在每条日志里重复写更可靠
想让每条日志都带上 trace_id、service_name 或 env，不要在每个 h.Infow() 里硬编码这些 key-value。用 log.With() 包一层原始 logger，后续所有 helper 都自动继承。
例如：
logger = log.With(logger, "service", "user-svc", "env", os.Getenv("ENV"))
h := log.NewHelper(logger)
h.Info("用户登录成功") // 自动含 service=user-svc env=prod
容易踩的坑：
• log.With() 返回新 logger，原 logger 不变，忘记赋值就白写了；
• 字段名冲突时（比如两次 log.With(..., "env", ...)），后一次会覆盖前一次，没有合并逻辑。
避免在 WithSource 配置加载前初始化日志组件
Kratos 启动顺序很关键：配置源（如 file.NewSource("config.yaml")）必须先于日志组件初始化。因为日志行为（比如是否写文件、日志级别）往往依赖配置项（如 log.level 或 log.file.enable）。
如果先 new 了 Zap logger，再去 load config，就会导致配置无法生效——日志组件已经构造完毕，后续读取到的配置只能靠手动 reload，而 Kratos 默认不提供这个机制。
正确顺序只有这一种：
- 调用
config.New(config.WithSource(...)) - 调用
c.Scan(&cfg)把配置映射到结构体 - 再根据
cfg.Log.Level、cfg.Log.File.Path等参数创建 logger 实例
这一步卡住的人不少：看着配置文件明明写了 log: {level: "warn"}，但 Info 日志还是满屏刷——大概率是 logger 初始化太早，压根没读到那行配置。
