这事儿挺有意思的，核心问题出在**fscanf对空白字符的处理逻辑**，以及%[^~]这类扫描集（scanset）的特殊行为上，咱们一步步拆解：

1. fscanf的空白处理规则 #

默认情况下，fscanf的格式串中，除了%c、%[、%n这三个格式说明符之外，其他所有格式都会自动跳过输入中的前导空白（空格、换行、制表符等）。而%[属于例外——它不会自动跳过前导空白，除非你在格式串里显式加一个空格。

另外，格式串里的空白字符（比如\n、空格）本身也会触发fscanf的“跳过所有连续空白”行为，直到遇到第一个非空白字符为止。

2. 第一种输入场景的失败原因 #

你的输入第一行是line1~blah，处理时：

• %[^~]读取line1直到~；
• ~匹配输入中的波浪线；
• %[^\n]读取blah直到换行符；
• 格式串最后的\n会让fscanf跳过所有连续空白——包括第一行的换行符，以及第二行开头的空格，直到遇到~为止。

这时候处理第二行 ~blah2时，%[^~]需要读取非~的字符，但文件指针已经停在~的位置了，完全没有可匹配的字符，所以fscanf直接返回0，后续的循环调用也因为指针位置卡在~这里，全部失败。

3. 交换行后正常的原因 #

当第一行是 ~blah2时，程序启动后文件指针在输入开头，%[^~]不会自动跳过前导空白，所以直接读取开头的空格（直到~），后续的~和%[^\n]都能正常匹配。处理完第一行后，格式串的\n跳过换行符，第二行line1~blah的开头是l（非空白），%[^~]能正常读取line1，自然就没问题了。

4. 为什么sscanf/fgets+sscanf能正常工作 #

• sscanf处理的是内存中的字符串，它不会像fscanf那样因为跨行为了跳过空白而移动指针，完全基于你传入的字符串内容处理；
• fgets会读取整行内容（包括换行符）到缓冲区，再用sscanf处理时，%[^~]能完整读取行开头的空格，不受之前输入处理的影响，自然不会出现匹配失败的情况。

修复建议 #

如果要保留fscanf的用法，最稳妥的方式是避免在格式串末尾用\n，换成明确读取换行符的方式，比如：

int n = fscanf( fp, "%[^~]~%[^\n]%*c", b1, b2 );

这里%*c会读取换行符但不存储（*表示抑制赋值），避免fscanf跳过后续行的前导空白。

不过考虑到遗留代码的规模，你提到的fgets+sscanf其实是更可靠的方案——它完全规避了fscanf自动跳过空白的坑，每一行的处理都是独立的，不容易出现这类诡异的问题。

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