go 默认字符串处理和 i/o 缓冲策略导致其在纯行读写场景下显著慢于 python；通过避免字符串转换、直接操作字节切片并合理使用缓冲，go 性能可反超 python。
在对比 Go 与 Python 的标准输入/输出性能时，一个看似简单的“逐行回显”任务（如 cat large_file | go_program）常暴露出令人困惑的结果：Python 2.x 的 for ln in sys.stdin: print ln, 竟然比等效 Go 程序快 3–4 倍。这并非 Go 语言本身低效，而是由默认行为差异和隐式开销共同导致的——理解并消除这些开销，是写出高性能 Go I/O 程序的关键。
核心瓶颈分析
-
字符串 vs 字节切片：UTF-8 安全性的代价
Go 的 scanner.Text() 返回 string，而 string 在 Go 中是不可变的 UTF-8 编码字节序列。每次调用 .Text()，bufio.Scanner 必须：- 验证输入字节是否为合法 UTF-8；
- 分配新内存拷贝字节并构造字符串头；
- 维护字符串只读语义（额外间接层）。
相比之下，Python 2.x 的 sys.stdin 行迭代器返回的是原始字节字符串（str），零编码检查、零额外分配——纯粹的 memcpy + write()。
-
输出未缓冲：系统调用爆炸
即使你已用 bufio.NewWriter(os.Stdout)，若仍调用 writer.WriteString(s + "\n")，就触发了两次额外开销：- s + "\n" 创建新字符串 → 再次内存分配 + UTF-8 合并；
- WriteString 内部再转为 []byte → 重复转换。
正确优化方案：全程字节操作
package main
import (
"os"
"bufio"
)
func main() {
reader := bufio.NewReader(os.Stdin)
scanner := bufio.NewScanner(reader)
writer := bufio.NewWriter(os.Stdout)
defer writer.Flush() // 确保所有输出写入
newline := []byte("\n")
for scanner.Scan() {
line := scanner.Bytes() // 直接获取 []byte，无字符串转换
writer.Write(line) // 写入原始字节
writer.Write(newline) // 写入换行符
}
// 可选：检查扫描错误（如 I/O 错误）
if err := scanner.Err(); err != nil {
os.Stderr.WriteString("scan error: ")
os.Stderr.WriteString(err.Error())
os.Stderr.WriteByte('\n')
}
}
os.Stderr.WriteByte('\n')
}
}✅ 关键改进点：
- scanner.Bytes() 替代 scanner.Text()：跳过 UTF-8 验证与字符串构造，复用底层缓冲区字节；
- writer.Write([]byte) 替代 writer.WriteString()：避免字符串→字节二次转换；
- defer writer.Flush() 确保缓冲区清空（否则末尾数据可能丢失）；
- 预分配 newline := []byte("\n") 避免循环内重复创建切片头。
性能实测对比（6500 万行词表）
| 实现方式 | real 时间 | user 时间 | 说明 |
|---|---|---|---|
| Python 2.7 (for ln in sys.stdin: print ln,) | 12.7s | 12.6s | 原生字节流，无编码开销 |
| 初始 Go（Text() + fmt.Println） | ~50s | — | 未缓冲 + 字符串转换双重惩罚 |
| 优化 Go（Bytes() + Write + NewWriter） | 4.4s | 4.3s | 快 Python 近 3 倍 |
? 提示：若需兼容 UTF-8 处理（如解析含中文的结构化日志），应明确权衡——scanner.Text() 提供安全保证，但代价真实存在；对纯管道转发、日志透传、二进制协议解析等场景，Bytes() 是更优选择。
总结：I/O 性能优化铁律
- 避免不必要类型转换：[]byte ↔ string 在高频 I/O 中是隐形杀手；
- 缓冲必须成对出现：bufio.Reader + bufio.Scanner 用于输入，bufio.Writer + defer Flush() 用于输出；
- 基准测试要公平：关闭终端输出（重定向到 /dev/null）、禁用 shell history、使用 time 而非主观感知；
- 警惕“玩具基准”的误导性：本文场景本质是内存带宽/系统调用效率测试，而非业务逻辑性能代表——但在构建 CLI 工具、日志处理器、ETL 流水线时，此类优化直接影响吞吐量上限。
掌握这些原则，你不仅能写出比 Python 更快的 Go I/O 程序，更能建立起对底层数据流的精准控制力。
