Go标准库log包没有Debug和Error方法，它们仅是第三方库功能；log.Error实为log.Println别名，无级别语义与过滤能力，真正分级需用zap等支持level控制的日志库。
Go 里 log.Debug 不是标准库函数，用了就报错；log.Error 虽然存在，但默认只输出到 stderr，不带级别过滤、不自动加时间戳——这不是“区分”，是“没区分”。
为什么 log.Debug 会编译失败
Go 标准库 log 包只有 log.Print/log.Printf/log.Println 和 log.Fatal/log.Panic 等，**根本没有 Debug 或 Info 方法**。常见错误是把其他日志库（比如 zap、logrus）的用法套到 log 上。
实操建议：
- 确认你 import 的是不是
"log"：如果是，删掉所有log.Debug，改用log.Printf+ 手动前缀，例如log.Printf("[DEBUG] user id: %d", uid) - 如果真要分级，直接换库：
zap（性能高）、zerolog（零分配）、logrus（生态熟），别硬改标准库 - 注意
log.SetFlags(0)会关掉时间戳和文件名，调试时容易丢上下文，慎用
log.Error 实际上只是 log.Println 的别名
标准库中没有 log.Error 函数。如果你看到代码里写了它，那一定是自己定义的，或来自第三方包。真实情况是：哪怕你封装了 Error，只要底层调的是 log.Println，它就和 Println 一样——无级别语义、无输出控制、无法动态开关。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 不要自己写
func Error(v ...interface{})包一层就以为有了日志级别；真正有用的是能统一控制「哪些级别写入、写到哪、是否格式化」的能力 - 若用
zap，logger.Error("msg", zap.String("key", "val"))才算真正分级；它的Error方法会走内部 level 判断，而标准库不会 - 调试时临时加
log.Printf没问题，但上线前必须清理或替换为可配置的日志器，否则log.Printf在生产环境照常输出，没法关
Debug 和 Error 的本质区别不在函数名，而在输出目标与可控性
区分的关键不是叫什么，而是：Debug 日志该不该出现在生产环境？Error 是否需要告警？是否要写入文件而非终端？这些都依赖日志器是否支持 writer 切换、level 过滤、字段结构化。
实操建议：
- 标准库
log.SetOutput(os.Stdout)或os.Stderr是全局的，不能按级别分流；zap可以用zapcore.NewCore配多个zapcore.WriteSyncer，让Error写文件 +Debug写 stdout - 用
log.SetPrefix("[ERROR]")模拟级别只是视觉欺骗，grep 时可能漏掉嵌套 error（比如fmt.Errorf("failed: %w", err)） - HTTP handler 中混用
log.Printf和http.Error容易导致错误被记录两次，且后者不带堆栈——要用zap的With(zap.Error(err))统一处理
真正难的不是选函数名，是决定什么时候关掉 Debug、怎么让 Error 自动触发 Prometheus 告警、以及确保 panic 堆栈也能进日志管道——这些标准库一个都不管。
