第一次往 arXiv 上挂预印本的人十个里有七八个会卡在同一个地方本地编译得好好的 PDF传上去之后要么报编译错误要么出来的版式和 Overleaf 里看到的完全不是一回事要么干脆在文件上传那一步就被打回来。更让人抓狂的是这类问题往往出现在论文已经改到第七八版、导师催着今天就挂上去的时候。这篇内容就把从 Overleaf 工程整理到 arXiv 页面点击 Submit 的整条链路拆开讲一遍重点放在那些官方帮助页面上写着但很容易被跳过的细节上。适合第一次投稿的新手照着走一遍也适合被 arXiv 折磨过几次、想搞清楚到底哪一步出了问题的人对照排查。整篇内容围绕 Overleaf 与 arXiv 两个工具之间的衔接地带展开因为绝大多数翻车现场都发生在这条缝里。1. 先把 arXiv 的规则摸清楚再谈排版很多人拿到投稿两个字脑子里第一反应是期刊那套流程——投稿系统、审稿意见、修改再投、录用。arXiv 完全不是这个逻辑它的定位是预印本存档你把已经写好的东西放上去让同行能早点看到、能引用。它不做同行评审也不对你的学术质量背书但它对你上传的东西能不能被正确编译和长期保存这件事管得非常严。理解了这个定位后面很多看似不近人情的规则就都能想通了。1.1 预印本平台和期刊投稿是两套逻辑期刊投稿系统关心的是这篇稿子值不值得送审所以它会让你填一堆覆盖信、推荐审稿人、利益冲突声明arXiv 关心的是这份源码我能不能在十年后还编译得出来所以它会强制你上传 LaTeX 源文件而不是 PDF会限制你用的宏包会检查你的图片格式。我第一次投稿时最不习惯的就是这一点明明 PDF 已经排版好了为什么还要我把.tex交出去后来才明白arXiv 存的是可复现的排版源PDF 只是它的一个渲染产物平台会用自己的 TeX Live 环境重新跑一遍你的代码跑出来的东西才算数。这个差异直接导致了一个高频事故你在 Overleaf 上看到的版式和 arXiv 编译出来的版式可能不一样。原因通常是 TeX Live 版本差异、宏包版本差异或者你本地用了某个 Overleaf 自带但 arXiv 环境里没有的字体。所以后面章节里我会反复强调一件事——不要相信 Overleaf 的预览结果要相信 arXiv 自己编译出来的那份 PDF。还有一点需要提前想清楚预印本一旦挂上去就算你后来撤稿元数据记录通常还是会留下痕迹版本号 v1、v2 也会一直跟着。所以提交前那次通读比期刊投稿前的通读更值得多花半小时。1.2 首次投稿绕不开的背书机制arXiv 有一个对新人不太友好的设计叫背书endorsement。简单说某些分类下你如果之前没有在这个分类发过文章系统会要求一位已经在该分类有投稿记录的作者给你做背书你才能提交。这个机制的本意是拦住批量灌水的账号但实际体验下来第一次投稿的人经常在这里卡住因为系统提示写得比较含蓄很多人以为是账号没验证好。处理方式有两条。一条是走机构邮箱验证如果你用的邮箱域名属于学术机构系统通常会自动给你解锁一部分分类的提交权限这是最省事的路径。另一条是找合作者或者熟悉的同行帮你背书你需要把系统生成的一串背书码发给对方对方在自己的账号里操作。我建议在正式动手整理文件之前先把账号注册、邮箱验证、分类权限这三件事确认掉不然你把源码收拾得再干净到提交那一步发现没权限还是白忙。另外提醒一句背书是分分类的你在某个分类拿到了资格不代表换个分类也能直接投。跨分类投稿前先看一眼提交页面的提示别等到填完所有元数据才发现下拉框里没有你想要的那个分类。1.3 分类代码选错后面全是返工arXiv 的分类是一套带层级代码的体系主分类primary决定你的文章出现在哪个列表里也会影响后续的引用检索。选分类这件事我的经验是优先选你论文最核心贡献所属的领域而不是你所在的院系。比如一篇做算法优化的文章如果核心创新在优化方法本身就应该选优化相关的分类而不是因为作者挂在某个应用方向的课题组就选应用分类。主分类之外还有 cross-list可以把文章同时挂到一到两个相关分类下。cross-list 不是越多越好挂三四个分类反而会让人觉得这篇文章定位不清。一般挂一个最相关的就够了除非你的工作确实是两个领域的交叉。选错分类最直接的后果是被人工审核打回重填中间要耽误一到两个公告周期。间接后果更麻烦分类不对目标读者根本刷不到你的文章预印本早发布早曝光的意义就打了折扣。我的建议是在提交前去目标分类下翻一下最近一周的列表看看同行的文章都是怎么归类自己这个土办法比读分类说明文档管用得多。2. Overleaf 项目要按可打包的标准来搭Overleaf 是个很好用的在线编辑器但它默认的项目组织方式是能编译就行而 arXiv 要求的是能打包、能在陌生环境里编译。这两者的差距就是大部分上传失败的根源。我在 Overleaf 里见过太多这样的项目图片散落在各个子目录、文件名带空格和中文、.bib和.bbl混着放、根目录下还躺着几个早期废弃的.tex。这种项目本地跑得飞快打成包传上去就开始报错。2.1 模板选择别一上来就自己造轮子如果你的论文还没有开始写最稳的做法是直接从 Overleaf 的模板库里挑一个官方或者社区维护的模板。选模板的时候看两个指标更新时间是不是近两年内以及模板说明里有没有明确提到兼容 arXiv。老旧模板最常见的问题是依赖了已经废弃的宏包或者用了某个特定 TeX Live 版本才有的命令上传到 arXiv 上直接编译失败。已经有稿子的情况更常见。这时候不建议推倒重来换模板因为换模板意味着所有图表位置、参考文献格式、页边距都要重新调工作量比修 bug 大得多。我的做法是保留原有模板但做三件事把根目录清理到只剩一个主.tex文件、把所有图片收进一个统一的figures/目录、把所有自定义命令集中到一个macros.tex里。这样做的目的是把隐式依赖变成显式引用编译时少一层不确定性。还有一个容易被忽略的点模板里的示例内容一定要删干净。我见过有人上传后发现编译出来的 PDF 里夹着模板作者的致谢段落原因是那段文字藏在某个.tex文件里没被引用到主文件但 arXiv 打包时会把它一起传上去。虽然不会编进最终 PDF但审核时看到多余文件容易被要求重新整理。2.2 目录结构与文件命名的大小写陷阱Overleaf 跑在 Linux 环境上arXiv 的编译服务器也是 Linux但你的本地电脑大概率是 Windows 或者 macOS。macOS 的文件系统默认大小写不敏感Windows 也不敏感而 Linux 是敏感的。这意味着你在本地写\includegraphics{Figures/result.png}实际文件名是figures/result.png本地能过arXiv 上一定报file not found。这类错误排查起来特别费时间因为报错信息只说找不到文件不会告诉你是因为大小写。我的习惯是所有目录名、文件名统一用小写单词之间用连字符或者下划线绝对不用空格。文件名里出现空格是另一个高频雷区虽然现代 TeX 引擎对空格的处理比以前好但在打包、解压、路径拼接这几个环节里空格仍然是最容易出问题的地方。目录层级也不要太深。figures/chapter1/experiments/这种三层嵌套在 Overleaf 里没问题但 arXiv 解压后路径处理偶尔会出岔子。我的建议是目录最多两层图片全部平铺在一个figures/下用文件名前缀区分章节比如fig1-overview.pdf、fig2-pipeline.pdf。这样既清楚又安全。2.3 编译引擎和字体本地能过不代表服务器能过Overleaf 的菜单里可以选编译器pdfLaTeX、XeLaTeX、LuaLaTeX。这三个在 arXiv 上的支持程度不一样。pdfLaTeX 是最稳的绝大多数模板都用它arXiv 对它的支持也最完整。XeLaTeX 支持但字体受限——你只能用 TeX Live 里自带的字体不能用系统里装的字体也不能用 Overleaf 上传的自定义字体文件。LuaLaTeX 的支持相对更有限一些。如果你的论文里有中文情况会更复杂。用 pdfLaTeX 加中文支持宏包是一种方案用 XeLaTeX 加字体配置是另一种方案两者在 arXiv 上的表现不完全一样。我踩过的坑是在 Overleaf 里用 XeLaTeX 配了一个上传的中文字体本地编译完美上传后字体找不到整篇中文变成空白。后来改成用 TeX Live 里自带的开源中文字体问题才解决。判断自己的项目该用哪个引擎最直接的办法是看模板说明。模板说用 pdfLaTeX 就别自作聪明换 XeLaTeX除非你有明确的字体需求。换引擎之前先在 Overleaf 里把编译器切换过去完整编译一遍确认没有警告堆积再考虑上传。2.4 用 Overleaf 的日志功能提前排雷Overleaf 编译完成后日志面板里会列出所有 warning 和 error。大部分人对 warning 是直接忽略的但在投稿场景下warning 值得看一眼。常见的几类图片分辨率不足、字体替换font substitution、未定义的引用、重复的标签。字体替换这一类尤其要注意它意味着你指定的字体在当前环境里不可用编译器偷偷换了一个。本地换了看不出差别arXiv 上换的可能就是你没想到的那个版式会跟着变。未定义的引用和重复标签在 Overleaf 里表现为问号但很多人习惯性点一下重新编译就消失了不去深究。实际上这类问题往往意味着.aux文件有残留打包上传后可能出现编号错乱。我的做法是上传前在 Overleaf 里做一次从零编译清空缓存Recompile from scratch看是否还能干净通过。能过说明项目是自洽的不能过说明有隐藏依赖。3. 打包上传arXiv 只认源码不认你的 PDF到了上传这一步很多人会下意识地把整个项目文件夹压缩一下丢上去。这一步的失败率相当高因为 Overleaf 导出的压缩包里包含了一些 arXiv 不需要甚至排斥的东西而你真正需要的东西可能反而没带上。理解 arXiv 到底要什么比反复试错快得多。3.1 必须带上 .bbl别指望服务器帮你跑 BibTeX这是最经典的一个坑值得单独拎出来说。arXiv 的编译流程不运行 BibTeX 或者 Biber它只跑 LaTeX 本身。也就是说你的参考文献列表必须在编译前就已经生成好以.bbl文件的形式存在。如果你只传了.bib和.tex编译出来的 PDF 里引用全是问号参考文献列表是空的。解决办法有两种。一种是在 Overleaf 里正常编译一次然后把生成的.bbl文件下载下来一起打包。Overleaf 界面上不直接显示.bbl你需要在项目菜单里找下载源码或者从编译输出里找。另一种是在本地跑一遍完整的编译链latex → bibtex → latex → latex把生成的.bbl拿出来。这里有个细节.bbl文件里的内容是跟你的.bib和引用顺序强绑定的。如果你在上传前又改了引用一定要重新生成.bbl不然会出现编号错位。我遇到过最诡异的一次是参考文献编号整体偏移了一位查了半天才发现是最后一次修改后忘了重新生成.bbl。用 biblatex 的项目要额外小心arXiv 对 biblatex 的支持不如传统 BibTeX 完整某些后端配置会直接失败。如果不是非用不可投稿版本建议退回传统 BibTeX。3.2 图片处理的三个硬指标图片这一块有三个指标需要盯着格式、体积、路径。格式上PDF、PNG、JPG 是最稳的。EPS 格式需要经过转换虽然现代 TeX 发行版自带转换工具但在服务器环境下偶尔会出问题能转成 PDF 就转成 PDF。矢量图优先用 PDF位图用 PNG照片类用 JPG这个顺序基本不会错。体积上整个上传包有个上限大致在几十 MB 的量级单张图片也不宜过大。高分辨率照片直接塞进去很容易把包撑爆。我的处理方式是照片类图片先压到 200 dpi 左右宽度控制在 2000 像素以内肉眼几乎看不出差别体积能降一个数量级。矢量图则要注意别把几十页的附录图全塞进正文包非必要的大图可以放到补充材料里。路径上前面说过大小写和空格的问题。这里再补一条图片文件名不要用中文也不要用%、#、这类在 LaTeX 和 URL 里有特殊含义的字符。看着是小问题实际排查起来能耗掉一整个下午。3.3 清理工程那些让编译失败的隐藏文件Overleaf 导出的压缩包里除了你自己的文件还可能包含编译缓存、.git目录、.DS_StoremacOS 生成的隐藏文件、以及一些自动生成的辅助文件。这些文件本身不一定导致失败但会干扰 arXiv 的文件扫描逻辑尤其是当包里存在多个.tex文件时系统需要判断哪个是主文件多余的文件会让它判断失误。我的清理清单是这样的删掉所有.aux、.log、.out、.toc、.synctex.gz删掉.git目录和任何隐藏文件确认根目录下只有一个.tex是主文件其余被\input或\include引用的文件放到子目录里确认没有备份文件.tex~、.bak。清理完之后在本地随便找个干净目录解压一遍用命令行编译一次能过再上传。这一步看起来繁琐但它能把上传后的失败率降到一个很低的水平。我现在的习惯是维护一个投稿版分支平时写作在主干上投稿时从主干切一个干净的分支出来专门做清理这样不会误删写作过程中还需要的东西。3.4 上传后先看编译日志别急着点 SubmitarXiv 的上传流程里有一个环节是它自己编译一遍然后给你看结果。这个环节很多人直接跳过看到编译成功就往下走。实际上这里应该点开看一眼生成的 PDF重点检查三件事页数对不对、图表位置有没有跑、参考文献是不是完整。如果编译失败页面会给出一段日志。日志通常比较长直接从最后往前找Error或者Fatal关键字比从头读快得多。常见的几类错误找不到文件路径问题、未定义命令宏包缺失或版本不符、编译超时图片太大或者 TikZ 图太复杂。超时这一类比较隐蔽日志里可能只写timed out你需要回头去精简那张图把它预先渲染成 PDF 再插入而不是每次编译都重新画一遍。4. 元数据填写标题、摘要、作者、分类的门道源码过了编译这一关接下来是填表。这部分看起来最简单实际上是最容易埋雷的地方因为填进去的内容会直接成为检索和引用的依据改起来比改源码麻烦得多。4.1 摘要字段是纯文本不是 LaTeXarXiv 的摘要输入框是纯文本字段不接受 LaTeX 命令。你在正文里写$\alpha$-divergence摘要框里就要写成alpha-divergence或者用 Unicode 字符。直接粘 LaTeX 代码进去轻则显示成一堆反斜杠重则被系统拒绝。摘要长度有上限一般控制在两千字符以内比较安全。这个长度足够写一段完整的技术摘要但不足以把整篇引言塞进去。我的写法是四句话问题是什么、现有方法差在哪、我们做了什么、结果如何。这四句话撑起来大概一千二百字符左右留足余量。还有一个细节摘要里的特殊字符。、%、_、#这些在 LaTeX 里有特殊含义的符号在纯文本摘要里虽然不需要转义但如果你的摘要会被下游系统拿去渲染最好还是避免或者用文字代替。换行在摘要框里通常会被合并成空格所以不需要刻意排版。4.2 作者列表与署名顺序的处理作者列表的填写顺序就是最终显示顺序这一点和大多数投稿系统一致。需要留意的是姓名格式系统一般会区分名和姓填的时候按字段来不要一股脑塞进一个框里。如果作者姓名里有连字符或者多个中间名按平时发表的习惯填就行。单位信息的填写有一个实际问题arXiv 上的单位信息是纯文本不能做复杂的排版也不能显示多个单位的对应关系。如果你的作者分属多个单位通常的做法是在作者名后面加编号然后在单位字段里按编号列出。但 arXiv 的显示效果有限复杂的多单位对应关系往往显示得很乱。我的建议是简化处理把主要单位列出来细节留给正文首页。通讯作者的身份在 arXiv 上不是通过元数据标记的而是通过账号本身。提交时用的账号会自动成为提交者这个信息是公开的。所以如果论文是代提交的要注意这一点。4.3 分类、cross-list 和 comments 字段主分类的选择前面说过了这里补充 cross-list 的策略。cross-list 会消耗额外的审核注意力挂太多分类可能被要求删减。一般一到两个足够选那些你的目标读者真正会去刷的分类。comments 字段是个容易被浪费的地方。它可以写页数、图表数量、以及一些补充说明。比如24 pages, 8 figures这种写法很常见方便读者快速判断篇幅。如果论文已经被某个会议接收也可以在这里注明但要注意措辞避免写成广告。这个字段有长度限制别写太长。还有一个字段是 journal reference如果你后来在期刊上发表了可以回来填上。这一步是可选的但填了对引用统计有帮助。4.4 许可证选项怎么选arXiv 提供几种许可证选项包括默认的永久许可和几种知识共享协议。这个选择需要和你的合作者、资助方确认因为对已发布的版本来说许可证一旦选定通常不能撤销。常见的几种默认许可是最宽松的允许 arXiv 长期存档和分发CC BY 允许他人自由使用只要署名CC BY-SA 要求衍生作品同样开源CC BY-NC-SA 额外限制商业使用。选哪个取决于你的项目要求如果资助方或者所在单位有明确规定按规定的来如果没有默认选项是风险最低的。我个人的经验是这个问题最好在提交前就和所有合作者达成一致不要在填表的时候临时讨论因为这一步点下去就回不了头了。5. 从提交到公告审核、卡稿和版本迭代点完 Submit 不等于结束从提交到正式出现在列表上中间还有一个过程这个过程的时间节奏和一些意外情况值得提前了解。5.1 公告时间窗口与晚一秒等一天arXiv 的公告是按天批量进行的每天有一个截止时间点在这个时间点之前完成提交并通过审核的会在当天的公告批次里出现错过了就顺延到下一个工作日。周末和节假日通常不公告。这个机制意味着一个很实际的问题如果你在截止时间前十分钟才提交而系统恰好需要人工审核那大概率赶不上当天。我的建议是留出至少半天到一天的缓冲尤其是第一次投稿不要卡着截止时间操作。具体的截止时间会随季节和平台安排调整提交页面会有提示以页面显示的为准。另一个影响节奏的因素是人工审核。首次投稿、分类敏感、内容需要确认的稿件会被放进人工审核队列。这个队列的处理时间不定短则几小时长则几天。5.2 被 on hold 的常见原因与应对提交后状态显示为 on hold意思是稿件在人工审核中。遇到这个不用慌绝大多数情况只是例行检查。常见的触发原因有几类首次在这个分类投稿、摘要里有需要确认的表述、文件里有多余内容、分类和内容匹配度存疑。应对方式取决于具体原因。如果是分类问题审核人员会发邮件说明你按要求调整后重新提交即可。如果是文件问题通常会指出具体是哪个文件。我的经验是收到邮件后尽快回复回复时把问题点逐条对应上不要含糊其辞这样能明显缩短处理时间。有一类情况需要特别注意如果审核人员认为你的稿件不符合平台的收录范围可能会拒绝收录。这种情况比较少见但一旦发生反复提交同一份内容没有意义需要先搞清楚问题出在哪。5.3 替换版本的正确姿势文章挂上去之后发现有个笔误或者有了新的实验结果可以提交新版本。新版本会以 v2、v3 的形式叠加arXiv 的编号不变旧版本依然可访问。这个设计对读者很友好对作者来说也提供了一个渐进完善的空间。替换的操作入口在你账号的稿件管理页面流程和首次提交类似重新上传源码、确认元数据、提交。有几点要注意替换版本也会经过编译检查所以同样要保证源码能干净编译如果只是小修不需要改动元数据系统会沿用之前的替换不是即时的同样要等公告周期。我见过的一个误区是有人以为替换会覆盖旧版本所以反复替换想改干净。实际上所有版本都留档读者能看到版本历史。所以与其反复替换不如一次改到位。5.4 撤稿这件事动手前想清楚撤稿withdrawal是不可逆的操作撤稿后稿件不会从系统里消失元数据会保留页面上会标注已撤稿。已撤稿的稿件不能再替换新版本。什么情况下需要撤稿通常是发现了严重错误或者论文内容不适合公开。轻微的笔误、补充实验、格式调整这些用替换版本就够了不需要撤稿。如果只是暂时不想让别人看到arXiv 没有隐藏这个选项撤稿是唯一的手段。所以提交前的最后一遍检查值得认真对待。我的习惯是提交前把 PDF 从头到尾读一遍重点看摘要、作者列表、图表编号、参考文献这四块这四块出错概率最高也最影响观感。6. 几个反复踩到的细节前面按流程走了一遍这里单独拎几个跨流程的细节出来都是我在实际操作中反复遇到、也反复看到别人遇到的。6.1 Overleaf 下载的 zip 里到底有什么从 Overleaf 下载源码包解压后你会看到一个和项目结构一致的目录。但里面通常还包含一些你没主动创建的文件编译生成的辅助文件、可能存在的.latexmkrc配置、以及一些编辑器自动加的元数据。这些文件不一定有害但会增加不确定性。我的处理方式是解压后先列一遍文件清单把不认识的、不是自己创建的文件挑出来逐个确认用途确认不了的就删掉。然后重新打包打包时注意不要在压缩包里再套一层目录——有些系统解压后会多出一层同名文件夹导致 arXiv 找不到根目录下的主文件。打包格式用 zip 最稳tar.gz 也支持但 zip 的兼容性更好。打包时确认压缩包里直接就是文件而不是压缩包/项目名/文件这种三层结构。6.2 编译超时与图片体积编译超时是一个很隐蔽的失败原因因为日志信息往往不直观。触发条件通常是TikZ 图太复杂、图片分辨率极高、参考文献条目极多、或者宏包加载过多。判断方法在本地用命令行跑一次完整编译计时。如果超过一分钟就有风险。优化手段按性价比排序把复杂 TikZ 图预先渲染成 PDF 再插入收益最大压缩图片分辨率和体积精简不必要的宏包把不参与正文的附录内容拆出去。我做过一次对比同一篇论文把三张复杂 TikZ 图预渲染成 PDF 之后编译时间从七十多秒降到十几秒包体积也小了一半。6.3 中文字符与特殊符号中文论文投 arXiv 的情况不少见但中文处理是整个流程里最容易出问题的一环。前面提过字体的问题这里再补两点。一是编码。源文件统一用 UTF-8 保存不要用其他编码否则在某些环节会出现乱码。Overleaf 默认是 UTF-8但从本地导入的老项目可能是别的编码需要在编辑器里确认一下。二是特殊符号。数学符号在摘要和标题字段里要转成文字或者 Unicode 字符不能直接写 LaTeX 命令。正文里的特殊符号则要注意宏包支持某些符号需要特定宏包而那个宏包可能在 arXiv 环境里的版本和你本地不一样。最后分享一个我自己在用的小习惯投稿前建一个检查清单把上面这些点列成勾选项每次提交前过一遍。清单不用长十几条就够但能挡住绝大多数低级错误。我第一次投稿时因为文件名里有个空格来回折腾了快两个小时第二次投稿前有了清单从整理源码到点击 Submit 一共四十分钟。这个投入产出比值得。
