清除神秘的引用标记

症状

该文档会编译，但在引用应该出现的地方，您会看到一个粗体问号“[?]”，并且日志包含诸如“LaTeX警告：引用’knuth84’未定义”之类的行。有时每个引用都会受到影响，有时只有一两个引用受到影响。因为这是警告而不是错误，所以 PDF 仍然可以构建，并且这些标记很容易被忽略，直到读者指出它们为止。

为什么会发生

LaTeX 不直接解析引用。在第一次传递时，它将每个请求的密钥记录在辅助文件中。然后，后端程序（“bibtex”或“biber”）在“.bib”数据库中查找这些键并写入格式化条目。另外两次 LaTeX 传递将结果折回。问号表示在最后传递时，该键不存在格式化条目。造成这种症状的每个原因都是某种破坏管道的方式。

按顺序找出原因

首先检查密钥本身。 \cite{knuth84} 和 @article{knuth1984,...} 是不同的字符串，并且匹配是精确的，包括大小写。在“.bib”文件中搜索警告中指定的密钥；任何一方的拼写错误都是最常见的罪魁祸首，日志中的第一个缺失键警告就是要追查的警告。

接下来，确保完整的编译周期运行。顺序是 LaTeX，然后是 bibtex 或 biber，然后是 LaTeX 两次。一次编译永远无法解析引用，因为后端尚未运行。 Oleafly 自动驱动整个周期，但手动构建或配置错误的编辑器可能会在第一次通过后停止。

第三，验证数据库路径。 \bibliography{refs} 和 \addbibresource{refs.bib} 相对于主文件解析，因此子文件夹中的数据库必须编写为 bib/refs 或 bib/refs.bib。错误的路径会悄然失败，并且通常会毁掉整个参考文献列表；对于更大的失败，请参阅空参考书目。

最后，将后端与系统进行匹配。加载 biblatex 的文档必须使用“biber”进行处理。给它提供经典的“bibtex”不会产生可用的输出，并且无论您重新编译多少次，每个引用都仍然是一个问号。

如果一切都失败了

陈旧的辅助文件可以保留旧的、损坏的状态。删除文档旁边的“.aux”、“.bbl”和“.blg”文件并从头开始重建。在删除之前，.blg 文件也值得阅读：它是后端自己的日志，并且明确命名了丢失的数据库和格式错误的条目。