feat:Replace the uniform 'info' with accurate log levels in the information output from the log

[liang9886703]

Description

This update focuses on optimizing the precision of log levels in output. It addresses the issue where all log calls (e.g., log.Debug/log.Warn) were uniformly mapped to the info level in the original logging system. By correcting the log level mapping logic, each log call type now corresponds to its actual intended level, resolving the problem of ambiguous log hierarchy and inability to distinguish the importance of information.

Example of Original Log Issue

The original logging system had incorrect level mapping—regardless of whether log.Debug or log.Warn was called, the output was always marked as info, leading to mixed log types:
Example 1：

log.Debug("hello")

Output incorrectly showed:

{"level":"info","time":"2025-11-30T15:15:49+08:00","caller":"/work/src/cards/application.go:107","message":"hello"}  // Debug info incorrectly labeled as info

Example 2：

log.Warn("hello")

Output still showed:

{"level":"info","time":"2025-11-30T15:15:49+08:00","caller":"/work/src/cards/application.go:107","message":"[callback]NextChar: "}  // Warning info incorrectly labeled as info

This incorrect mapping mixed debug details, warning prompts, and normal process information, significantly reducing the filtering value of logs and efficiency in issue troubleshooting.

Optimized Examples & Explanation

After fixing the log level mapping logic, log call types now accurately match the output levels:

1. Warning Calls (log.Warn):

   log.Warn("appId:[1] is not exist, use default appid")

   Output corresponds to the warn level to highlight risk prompts:

   {"level":"warn","time":"2025-11-30T15:29:53+08:00","caller":"/work/src/router.go:158","message":"appId:[1] is not exist, use default appid"}

2. Debug Calls (log.Debug):

   log.Debug("[fi...")

   Output corresponds to the debug level to retain troubleshooting details:

   {"level":"debug","time":"2025-11-30T15:29:53+08:00","caller":"/work/src/router.go:162","message":"[fi..."}

Post-optimization, log levels fully align with the actual type of information. This enables quick filtering of warning risks, debug details, or core process information by level, greatly improving log analysis efficiency and accuracy in issue localization.

[soltanoff]

Looks good to me, thank you!

Before merge, I'll test (or add some test cases) for debug/war/error logs. It would be nice if you can add it.

[Copilot]

Pull request overview

This pull request fixes a critical bug in the logging system where all log calls (Debug, Warn, Error, Fatal) were incorrectly outputting logs with the "info" level. The fix updates the internal logger methods to accept and use zerolog.Level types instead of hardcoded string values, ensuring each log method now outputs with its correct corresponding level.

Key Changes:

• Modified log() and msg() helper functions to accept zerolog.Level parameter instead of string
• Updated all public logging methods (Debug, Info, Warn, Error, Fatal) to pass appropriate zerolog.Level constants
• Changed from hardcoded .Info() calls to dynamic .WithLevel(level) calls in the logger implementation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.