这是一个创建于 1090 天前的主题，其中的信息可能已经有所发展或是发生改变。
看网上很多例子，日志统一输出到 os.Stderr 。
当然也有 os.Stdout 的。
想请教下，在实际环境上，这两者的不同。
 |
1
msg7086 2023 年 1 月 28 日
生产的时候哪个都不用，走日志库发送到中央日志系统。
|
 |
2
jifengg 2023 年 1 月 28 日  5
个人觉得，看软件的输出类型。
比如你的程序是服务型的（比如一个 http 服务），不靠控制台做输出或不输出管道，则 stdout 或 stderr 都可以。 如果是工具型的（比如 grep 、ffmpeg ），通过控制台输出结果的，那么日志就应该输出到 stderr ，避免和正常的 stdout 混淆了。 |
 |
3
plko345 2023 年 1 月 28 日
stdout 吧, 基本都是这么做的吧, 而且现在容器化, 也都是这么做的
|
 |
4
julyclyde 2023 年 1 月 28 日 1
|
 |
6
ql562482472 2023 年 1 月 28 日
stdout 啊
|
 |
7
guanzhangzhang 2023 年 1 月 28 日
最优雅的还是 env 或者配置文件支持类似 DSN 那样的配置，支持 stdout 也支持远端集中日志，以及 format 是 json 还是 line 啥的
|
 |
8
tool2d 2023 年 1 月 28 日
推荐 os.Stdout ，这样还可以用管道，让别的程序实时二次加工 /过滤你的 log 内容。
|
 |
9
nightwitch 2023 年 1 月 28 日 via Android
生产环境下一般往 socket 或者 file
|
 |
10
feelinglucky 2023 年 1 月 28 日
@julyclyde 让日志库去实现好了，应用只是调用不关心细节
|
 |
11
GopherDaily 2023 年 1 月 28 日
stdout ，逻辑分层，输出日志就输出日志，后续的收集、分类存储没必要耦合
|
 |
12
MrKrabs 2023 年 1 月 28 日
看心情
|
 |
13
soulsxd 2023 年 1 月 29 日
统一 stdout ，然后日志打印加上日志级别用于过滤
|
 |
14
Nexora 2023 年 1 月 29 日
系统正常日志，输出到 os.Stdout, 系统错误日志输出到 os.Stderr , linux 上命令行程序的日志都是这个规则。
|
 |
15
mxalbert1996 2023 年 1 月 29 日 via Android
@tool2d stderr 也可以，加个 2>&1 就行
|
 |
16
libook 2023 年 1 月 29 日
这其实就是个约定问题，你可以看一下为什么系统要设计 stdout 和 stderr 两个通道，然后再看一下自己项目的设计如何利用这两个通道。
|
 |
17
jim9606 2023 年 1 月 29 日 via Android
如果你打算用 systemd 、docker 等管理服务日志，用 stdout 问题不大
如果本身有 CLI 交互的就得换 stderr 了 |
 |
18
tairan2006 2023 年 2 月 7 日
stdout 啊，因为 go 的 panic 会输出到 stderr ，你需要单独捕获 panic 的日志的话，就不要向 stderr 里面输出任何业务信息。
|
 |
19
lotusgrm 2023 年 7 月 27 日
1 、如果服务是容器化的，建议将容器的日志输出到 stdout 和 stderr ，这里主要有这么 2 个原因吧：（ 1 ）方便日志的集中管理。将容器日志输出 stdout 和 stderr 可以很方便的通过管道重定向到其它的日志管理平台，这样一来的话所有容器的日志可以集中存储和分析 （ 2 ）容器化标准化。将日志输出 stdout 和 stderr 有助于将容器设计为只负责应用程序进程本身，而不用关心日志的具体实现，比如我们可以通过 sidecar 的方式收集封装服务日志
2 、具体是输出 stdout 还是 stderr ，我个人觉得可以根据日志级别来决定，比如 nginx 中有两类很重的日志:access.log 、error.log ，前者表示正常的访问日志，后者表示错误日志，一般情况我觉得我们的业务系统可以参考 nginx 的设计建立这两类日志 |
Select Language