第一次往 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_Store（macOS 生成的隐藏文件）、以及一些自动生成的辅助文件。这些文件本身不一定导致失败，但会干扰 arXiv 的文件扫描逻辑，尤其是当包里存在多个.tex文件时，系统需要判断哪个是主文件，多余的文件会让它判断失误。
我的清理清单是这样的：删掉所有.aux、.log、.out、.toc、.synctex.gz；删掉.git目录和任何隐藏文件；确认根目录下只有一个.tex是主文件，其余被\input或\include引用的文件放到子目录里；确认没有备份文件（.tex~、.bak）。清理完之后，在本地随便找个干净目录解压一遍，用命令行编译一次，能过再上传。
这一步看起来繁琐，但它能把上传后的失败率降到一个很低的水平。我现在的习惯是维护一个"投稿版"分支，平时写作在主干上，投稿时从主干切一个干净的分支出来专门做清理，这样不会误删写作过程中还需要的东西。
3.4 上传后先看编译日志，别急着点 Submit
arXiv 的上传流程里有一个环节是它自己编译一遍，然后给你看结果。这个环节很多人直接跳过，看到"编译成功"就往下走。实际上这里应该点开看一眼生成的 PDF，重点检查三件事：页数对不对、图表位置有没有跑、参考文献是不是完整。
如果编译失败，页面会给出一段日志。日志通常比较长，直接从最后往前找"Error"或者"Fatal"关键字，比从头读快得多。常见的几类错误：找不到文件（路径问题）、未定义命令（宏包缺失或版本不符）、编译超时（图片太大或者 TikZ 图太复杂）。超时这一类比较隐蔽，日志里可能只写"timed out"，你需要回头去精简那张图，把它预先渲染成 PDF 再插入，而不是每次编译都重新画一遍。
4. 元数据填写：标题、摘要、作者、分类的门道
源码过了编译这一关，接下来是填表。这部分看起来最简单，实际上是最容易埋雷的地方，因为填进去的内容会直接成为检索和引用的依据，改起来比改源码麻烦得多。
4.1 摘要字段是纯文本，不是 LaTeX
arXiv 的摘要输入框是纯文本字段，不接受 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 一共四十分钟。这个投入产出比，值得。
