Operator SDK 默认日志输出不到 kubectl logs 是因为 zap logger 未显式设置 OutputPaths，默认写入文件而非 stdout/stderr；需配置 OutputPaths=["stdout"] 并调用 defer logger.Sync() 确保日志刷出。
Operator SDK 默认日志为什么输出不到 kubectl logs
因为默认 zap logger 没有显式指定 OutputPaths，它会 fallback 到文件写入（如 /tmp/zap-*.log），而 Kubernetes 只采集容器主进程的 os.Stdout 和 os.Stderr。你看到 kubectl logs 为空，不是日志没打，是根本没往 stdout 写。
- 验证方式：
go run main.go | cat -看是否有输出；无输出说明日志被重定向到文件了 - 必须显式设置
OutputPaths: []string{"stdout"}或OutputPaths: []string{"/dev/stdout"} -
zap.Development: true会自动用consoleEncoder并输出到 stderr，但仅限开发模式，生产部署时仍需手动配OutputPaths - 别忘了在
main()结尾加defer logger.Sync()，否则缓冲区日志可能丢失
如何在 main.go 中正确初始化结构化 logger
Operator SDK 脚手架生成的 main.go 里，ctrl.SetLogger 的调用位置和参数顺序直接影响日志是否生效。直接覆盖默认行为比 patch flag 更可靠。
- 删掉或注释掉
opts.BindFlags(flag.CommandLine)+flag.Parse()这套命令行绑定逻辑（除非你真需要动态传参） - 改用硬编码配置构造 logger：
logger := zap.New(zap.UseDevMode(true), zap.Output(zapcore.Lock(os.Stdout)), zap.Encoder(zapcore.NewConsoleEncoder(zapcore.EncoderConfig{ TimeKey: "ts", LevelKey: "level", NameKey: "logger", CallerKey: "caller", MessageKey: "msg", StacktraceKey: "stacktrace", EncodeLevel: zapcore.LowercaseLevelEncoder, EncodeTime: zapcore.ISO8601TimeEncoder, EncodeCaller: zapcore.ShortCallerEncoder, EncodeDuration: zapcore.StringDurationEncoder, }))) - 再调用
ctrl.SetLogger(logrusr.New(logger))（需引入github.com/go-logr/logrusr）或直接用ctrl.SetLogger(zapr.New(logger))（SDK v4+ 支持原生 zap.Logger） - 确保
setupLog = ctrl.Log.WithName("setup")在 logger 初始化之后执行
--zap-log-level 和 --zap-stacktrace-level 实际作用差异
这两个 flag 都控制日志级别，但作用域和触发条件完全不同，混用容易误判问题根源。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
--zap-log-level控制全局最低日志等级（debug/info/error），低于该级别的Info()、Error()调用直接被跳过 -
--zap-stacktrace-level只影响「是否附加 stacktrace」——仅当某条日志等级 ≥ 该值时，才在日志中注入调用栈（例如设为error，则只有Error()和DPanic()日志带 stacktrace） - 它们不改变日志内容本身，只影响输出开关和附加字段；若发现日志突然变少，优先检查
--zap-log-level是否被设成error导致Info()全部消失 -
--zap-devel开启后会强制使用 console encoder 并忽略--zap-encoder json，调试时方便，但上线前必须关掉
Reconciler 中写结构化日志的常见错误写法
很多人以为 log.Info("reconciling", "name", req.NamespacedName) 就算结构化了，其实 key-value 对没对齐、类型错位、漏 defer，都会让日志不可读或丢失。
立即学习“go语言免费学习笔记（深入）”；
- 避免裸字符串做 key：
log.Info("reconciling", "namespace", req.Namespace, "name", req.Name)—— 不要用"ns"或"n"这类缩写，下游采集器无法标准化解析 - 不要把 error 当 value 传：
log.Error(err, "failed to get pod")是正确用法；log.Info("failed to get pod", "err", err)会导致 err 被转成字符串，丢失堆栈和类型信息 - Reconciler 方法内不要重复
ctrl.Log.WithName(...)，应在SetupWithManager里绑定 logger：r := &MemcachedReconciler{ Client: mgr.GetClient(), Log: ctrl.Log.WithName("controller").WithName("memcached"), Scheme: mgr.GetScheme(), } - 所有
log.Info/log.Error调用后，如果用了defer logger.Sync()，必须确保该 defer 在整个 Reconcile 函数结束前未被提前释放（比如在 goroutine 里 defer 就无效）
OutputPaths，若 zap encoder 没设 EncodeLevel: zapcore.CapitalLevelEncoder 或没加 zap.AddStacktrace(zapcore.ErrorLevel)，某些低频 error 可能卡在缓冲区里迟迟不刷出——这不是日志没打，是它还没来得及出来。 
