C语言中while循环读取stdin直到EOF的典型写法是while ((c = getchar()) != EOF)，因其在读取时同步判断返回值，避免feof()滞后导致的重复读取或漏读。
while 循环读取 stdin 直到 EOF 的典型写法
在 C、C++、Python 等语言中，while 循环配合输入函数判断返回值是否为 EOF（或 None、false）是最直接的方式。关键不是“用 while”，而是“用什么条件判断流已结束”——错误地用 while not eof() 或先读再判，极易漏掉最后一行或陷入死循环。
- C 语言中应写成
while ((c = getchar()) != EOF)，而不是while (!feof(stdin)) { c = getchar(); ... }；后者在文件末尾时feof()尚未置位，会多读一次失败值 - Python 中推荐
for line in sys.stdin:，若必须用while，则用line = sys.stdin.readline()并检查if not line:（空字符串表示 EOF），不要用sys.stdin.read(1)配合while True - Java 的
Scanner.hasNextLine()可安全用于while条件，但注意它不阻塞；若输入来自管道且提前关闭，可能抛NoSuchElementException
为什么 readline() 比 read() 更适合逐行处理
readline() 天然按行边界切分，返回含换行符的字符串（或空串 EOF），逻辑清晰；而 read() 默认读全部内容，对大流易爆内存，设长度又难适配不同平台换行符（\n、\r\n）。
- Python 中
sys.stdin.readline()在 Linux/macOS 下读到\n即返回，在 Windows 下也能正确识别\r\n并返回含\n的字符串 - C 的
fgets(buf, size, stdin)同样安全：它最多读size-1字节，自动补\0，且只要遇到\n或 EOF 就停止，不会跨行截断 - 避免用
input()（Python）或scanf("%s", buf)（C）：前者遇 EOF 抛EOFError，需额外异常处理；后者跳过空白后才读，会吞掉空行和首字段前的空格
管道/重定向场景下容易忽略的 EOF 表现
从终端交互输入时按 Ctrl+D（Unix）或 Ctrl+Z（Windows）触发 EOF；但通过 cat file.txt | ./a.out 或 ./a.out 时，EOF 是静默发生的——此时若循环逻辑依赖“用户按键”，就会卡住或行为异常。
- 测试时别只用手动输入：用
echo -e "a\nb\nc" | ./a.out验证是否能正确处理三行后退出 - 某些语言（如 Rust 的
std::io::stdin().lines()）返回的是Result<string></string>，需用while let Ok(line) = lines.next()，否则忽略Err会导致 panic - Shell 中重定向文件时，如果文件末尾无换行符，部分语言（如 Python）的最后一次
readline()仍返回非空字符串（最后一行内容），只有下一次才返回空串——这是符合 POSIX 的行为，不是 bug
性能敏感场景下的缓冲与阻塞控制
默认 stdin 是行缓冲（交互式）或全缓冲（重定向），频繁调用小读取会放大系统调用开销。真有性能要求时，不应靠改 while 结构，而应换批量读取策略。
- Python 中可改用
sys.stdin.buffer.read(8192)手动分块解析，但需自己处理跨块换行符；sys.stdin.read()仅适用于确定小数据 - C 中用
setvbuf(stdin, NULL, _IOFBF, BUFSIZ * 4)扩大缓冲区，但注意这必须在任何输入操作前调用，且对交互式终端可能失效 - Node.js 的
process.stdin是流对象，直接监听'data'和'end'事件比用while更自然；强行用while (chunk = await readChunk())会丢失流式优势
实际业务里最常出问题的，是把“判断流结束”和“处理当前数据”拆成两步，又没处理好中间状态。比如先 read() 再 if data:，但忘了 read() 在 EOF 时返回空字节而非 None，结果空数据被当成有效输入处理了。
