首先直接给出结论：这种行为不完全符合C语言标准的严格要求，但背后是终端交互式输入的特殊实现逻辑导致的。下面分两部分详细解释：

1. 是否符合C标准？ #

根据C语言标准（以C17版本为例）：

• 明确规定当流的EOF标志被设置后，若后续输入操作成功读取到数据，必须清除EOF标志（参考C17 §7.21.1p7）。
• 如果你的平台在成功读取字符后，EOF标志仍然保持为true，这明显违反了标准的要求。
• 不过对于交互式终端这类特殊输入流，标准允许实现有一定灵活性——比如允许在触发EOF后继续读取新输入，但流状态的处理仍需遵循标准规则。

2. 产生该现象的原因 #

问题核心在于终端EOF快捷键和C标准中EOF概念的本质差异：

• 终端快捷键不是真正的EOF：Unix的Ctrl+D、Windows的Ctrl+Z是终端提供的交互快捷键，作用是告诉终端「立即把当前输入缓冲区的内容发送给程序」。如果按下快捷键时缓冲区为空，终端才会向程序发送EOF信号，触发stdin的EOF标志；但如果之后你又输入普通字符，终端会重新将这些字符送入缓冲区，程序的stdin流就能再次读取到数据——这是终端的交互式特性，并非C标准强制的行为。
• 平台特定的流状态处理：正常情况下，当getchar()成功读取到新字符时，应该自动清除EOF标志。但你的平台可能在实现上没有严格遵循这一点，导致读取后EOF标志依然保留。这种情况属于平台的非标准扩展行为，常见于某些终端环境或特定的libc实现中。

举个具体场景：你先按Ctrl+D（此时输入缓冲区为空），第一个getchar()返回EOF，feof(stdin)被设为true；接着你输入字符'a'，终端把这个字符送入缓冲区，第二个getchar()成功读取到'a'——按照标准，此时feof(stdin)应该被重置为false，但你的平台没这么做，这就是不符合标准的地方。

内容的提问来源于stack exchange，提问作者effeffe