日志没输出大概率是Logger未注册或Helper拿到NopLogger：需检查main.go中是否注册有效Logger（如zap.NewZapLogger）、确认无误传log.NewNopLogger()、排除DI失败或Filter拦截，并验证日志等级与输出目标。
日志没输出，大概率不是代码写错了，而是 Logger 实例根本没注册进框架、或者 Helper 拿到的是 log.NewNopLogger() 这类静默实现。
Logger 没注册或被覆盖成 NopLogger
Kratos 不会自动创建可用的 Logger，你必须显式注册一个可工作的实例。如果漏掉这步，helper.Info() 看似调用成功，实际什么都不会打出来。
- 检查
cmd/<service>/main.go</service>中是否调用了app.RegisterComponent(zap.NewZapLogger())或类似初始化语句 - 确认没有在某处误传了
log.NewNopLogger()给业务层（比如NewUserRepo(data, log.NewNopLogger())），它真的一行都不输出 - 别用
log.Default()—— 它和 Kratos 的log.Logger接口不兼容，字段格式错乱，且可能被框架忽略
Helper 没拿到正确的 Logger 实例
Helper 是包装器，它背后依赖注入的 Logger。如果 DI 失败或传参错误，Helper 就成了空壳。
- 检查 Repo/Service 初始化时传入的
logger参数是否为nil：传nil会导致运行时 panic，但某些旧版封装可能悄悄 fallback 到 NopLogger - 确认 wire 注入路径里没有遗漏
log.Logger类型绑定，尤其当多个组件共用 logger 时，容易因命名冲突或 provider 返回nil导致失败 - 在 handler 开头加一行
helper.Debug("test")并观察——如果连这行都不出，基本锁定是 logger 实例未就绪
日志等级或过滤器把输出拦掉了
默认日志等级可能是 LevelInfo，而你打的是 Debug；或者 Filter 配了全局脱敏/拦截逻辑，把整条日志吞了。
- 临时把
helper.Debug()改成helper.Info()测试，排除等级问题 - 检查是否启用了
log.WithFilter()，特别是自定义 Filter 实现里有没有无条件 return 或误判level - 确认配置文件中日志 level 设置没被环境变量覆盖（如
KRATOS_LOG_LEVEL=warn）
输出目标被重定向或缓冲未刷新
日志写到了文件但你没看对地方，或者 stdout/stderr 被捕获、缓冲导致延迟甚至丢失。
- 查
internal/logger/zap.go或类似初始化文件，确认core的WriteSyncer是否指向os.Stdout，而不是某个被关闭的文件句柄 - 容器环境下，确保没把
stdout重定向到 /dev/null 或被 logrotate 截断；Kubernetes Pod 日志只收标准输出，别往文件里写 - 调试时可在
helper.Info()后手动加os.Stdout.Sync()（仅限本地验证），看是否是缓冲问题
最隐蔽的点往往在组件注册顺序：Logger 必须在所有依赖它的组件（比如 Repo、Middleware）之前注册，否则那些组件拿到的就是未初始化的空实例。kratos-bootstrap 要求显式传入服务名和版本号，这个过程本身也依赖 logger —— 如果 logger 没先就位，bootstrap 甚至可能 panic 前就静默失败了。
