arXiv投稿与Overleaf准备：预印本工程整理与上传校验

1. 先把投稿当成一次构建发布来看第一次把稿子推到 arXiv 上的时候我在 Overleaf 里点了一下编译绿色的对勾亮着PDF 干干净净心想这事十分钟就能搞定。结果上传完平台回给我的编译日志里躺着七条错误最扎眼的一条是找不到图片文件。后来才发现是我在本地用了一个带空格的中文目录名而平台解压之后路径全变了。从那次开始我养成一个习惯把 arXiv 投稿当成一次构建发布来做而不是上传一个 PDF。这两件事的差别很大——前者要考虑目标环境的编译器版本、文件路径、依赖完整性后者只关心我这台机器上能不能跑。这篇内容讲的就是这条链路怎么在一个在线协作编辑器下文统一叫 Overleaf里把工程整理成随时可以打包的形态怎么把元数据填到不容易返工怎么读懂上传之后那一大段编译日志以及提交之后状态怎么流转。核心关键词是arXiv 投稿和Overleaf 准备我把它们拆成两个独立但咬合的阶段前半段解决文件层面能不能编译通过后半段解决元数据层面能不能被正确归档和检索。适合谁看第一次投预印本、还没搞清楚分类和许可证区别的人稿子已经在 Overleaf 里写完、但不知道怎么导出成可提交包的人以及合作者众多、需要把工程交给别人复现的团队。如果你已经投过三五次这篇里关于 bbl 文件、字体嵌入、公告截止时间的那几节应该还能帮你省掉一两次返工。所有内容都基于我自己的操作经验和常见实践具体规则以平台当时的页面提示为准因为这类平台的功能和限制是会调整的。1.1 预印本平台在这条链路上到底承担什么很多人对预印本平台的定位是模糊的觉得它是一个免费的发表渠道。这个理解会带来一连串误判。它更像一个带时间戳的公开存档你上传一份稿件平台给它一个永久标识、一个提交日期、一个版本号然后把它放进公开可检索的索引里。它不做同行评审不做学术判断也不保证内容正确性。它能给你的东西是我比你早这个事实记录以及一个可被引用的条目。理解这一点很多事情就顺了。比如为什么它可以接受格式不那么完美的稿件——因为它不是排版终端最终排版是期刊的事。比如为什么它对源码结构那么挑剔——因为它的目标不是让你交一份漂亮的 PDF而是让任何人下载源码后都能重新编译出同样的结果这是长期存档的基本要求。再比如为什么提交之后还能替换版本——因为存档允许同一份工作的演进v1 永远留在那里v2 覆盖的是展示层。我在实际操作中的体会是把它当成给未来的自己留一份可编译快照来准备通过率会高很多。你交付的不只是一篇论文而是一套能在陌生环境里复现的构建材料。1.2 全流程的五个阶段与时间预算整个流程我拆成五段每段有明确产出物和典型耗时。把它写在纸上之后就不会出现以为半小时能搞定、结果卡了一整晚的情况。阶段主要动作典型耗时最容易出问题的地方一、工程整理目录重排、依赖补齐、清理中间文件1 到 3 小时图片路径、bbl 缺失二、元数据准备标题、摘要、作者、分类、许可证30 到 60 分钟分类选错、摘要含特殊符号三、上传校验打包上传、读日志、修错重传30 分钟到 2 小时编译失败反复试四、等待处理状态从提交到公告数小时到数个工作日被挂起、需要补充说明五、后续维护替换版本、修订元数据、引用更新按需版本号混乱时间预算里最容易被低估的是第一阶段。大家的直觉是稿子都写完了整理能花多久实际上跨平台迁移带来的路径问题和宏包差异往往比写作本身更磨人。我一般会给自己留出一个完整工作日并且强制要求不要等到截止时间前两小时才开始打包。提示公告是有固定节奏的超过当天的截止时刻就会被顺延到下一个公告批次。这条规则意味着提前一天和卡最后一小时的结果可能差出好几天尤其碰上连续假期。1.3 三个硬约束最好在动手前就搞清楚第一个约束是分类与推荐确认。平台按学科分成若干大类每个大类下有细分子类你提交时选的那个叫主分类它决定了你的稿子进入哪个公告列表、推送给哪批订阅者。部分子类对新提交者有额外要求需要有已有提交记录的作者做推荐确认。这条规则卡住过不少人——稿子整理得完美结果在提交页面发现当前分类不接受新提交者只能临时换分类或者去找人帮忙确认。第二个约束是文件白名单与体积上限。平台只接受特定格式的源码和图片超出的格式会被直接拒绝或者忽略。压缩包总大小也有上限具体数值以提交页面显示为准。这个限制对做图像、做数据集、附录塞了大量图的人特别不友好需要提前规划图片压缩策略。第三个约束是许可证的不可逆性。你在提交时选择的授权条款一旦稿子公开就很难再改回去。这不是技术问题是策略问题。我个人建议如果这项工作后续要投的期刊有明确的授权要求先确认期刊那边的规定再回来选平台这边的选项顺序反了就要返工。至于学术规范层面的问题比如这份稿子是否已经在别处进入审稿流程、目标期刊对预印本的态度如何这些需要在投稿前就确认清楚不要等公开了再回头处理。2. Overleaf 工程改造让它在别人的编译器上活下来Overleaf 用起来太顺手了顺手到你容易忘掉一件事它背后是一整套被配置好的编译环境宏包齐全、字体齐全、路径宽松。而你要提交的目标环境是另一套配置版本可能不同宏包可能缺失路径处理更严格。所谓Overleaf 准备本质是把工程从在我这儿能跑改造成在陌生环境里也能跑。我踩过最典型的一个坑本地用了一个只在较新版本里才有的命令Overleaf 上编译正常上传后报 undefined control sequence。原因不是命令本身有问题而是目标环境的发行版版本偏旧。解决办法有两个方向一是把该命令换成兼容写法二是把所需的宏包文件一并打包上传。前者更干净后者更省事但会增加包体积。我一般优先选前者因为兼容写法通常也就多写两三行。2.1 目录结构与命名约定目录结构这件事平时怎么写都行但要提交就得收敛成一套保守的约定。我的标准布局是这样paper/ ├── main.tex ├── sections/ │ ├── intro.tex │ ├── method.tex │ └── experiments.tex ├── figures/ │ ├── fig1.pdf │ └── fig2.pdf ├── refs.bib ├── main.bbl └── styles/ └── custom.sty三条硬规则。第一主文件唯一且文件名不要用paper final version 3.tex这种带空格和中文的写法。目标环境解压之后对空格和大小写的处理不一定友好而大小写敏感的文件系统会把Fig1.PDF和fig1.pdf当成两个不同的东西本地能跑、上传就找不到文件。第二所有图片进 figures 目录所有自定义样式进 styles 目录不要散落在根目录。第三不要用绝对路径\includegraphics里出现的路径必须是相对主文件的相对路径。命名上还有个小细节避免在文件名里出现#、%、、$这些在 TeX 里有特殊含义的字符。它们在\input和\includegraphics的参数里会被当成语法而不是文件名报错信息往往指向莫名其妙的行号排查起来很费时间。注意改名之后一定要全局搜索一遍引用。批量重命名图片是排查成本最高的一类问题因为报错只说文件找不到不说你半年前把这张图改过名字。2.2 主文件与编译链的关键配置主文件的第一行决定了整条编译链。\documentclass之后最好显式声明需要的引擎特性。跨平台迁移时最常见的三类失败字体缺失、引擎不匹配、外部命令调用被禁。字体问题几乎全部来自 XeLaTeX 或 LuaLaTeX 路线。如果你在本地用了系统里装的某个中文字体上传之后那台机器上没有这个字体编译直接中止。稳妥做法是换成平台自带字体集里的字体或者干脆用 pdfLaTeX 加 CJK 宏包走传统路线。如果你的稿子确实是中文为主我建议先在目标引擎下做一次空跑测试把字体问题提前暴露出来别等全稿上传后才发现。引擎不匹配的典型症状是\pdfoutput相关的报错或者某些绘图宏包在错误引擎下直接崩。这个只能靠实际测——把引擎切换成目标环境常用的那个在本地完整编译一遍看有没有警告。外部命令调用被禁指的是那些需要开启 shell 逃逸才能工作的宏包比如带代码高亮的minted它要调用外部脚本、某些需要外部转换的图形工具。这类宏包在受限环境里通常不可用。我的处理办法是把代码高亮换成纯 TeX 实现的方案虽然样式朴素一些但省掉了一整类兼容问题。写稿阶段怎么方便怎么来提交前把这些依赖外部进程的部分全部替换掉是一条很划算的取舍。\documentclass[11pt,a4paper]{article} \usepackage[T1]{fontenc} \usepackage[utf8]{inputenc} \usepackage{graphicx} \usepackage{amsmath,amssymb} \usepackage{booktabs} \graphicspath{{figures/}} \begin{document} \input{sections/intro} \end{document}上面这段的关键在于\graphicspath。把所有图片路径前缀统一声明一次正文里就只写文件名迁移目录结构时改动量最小。这是一个很小的习惯但能省掉大量重复劳动。2.3 参考文献必须自带干粮这是我见过最多人栽跟头的地方。Overleaf 里点一下编译参考文献自动生成看起来一切正常。上传之后所有引用变成问号参考文献列表空空如也。原因很简单本地那次编译里工具链自动跑了文献处理程序而目标环境里那一步不一定被执行或者执行了但找不到你本地的样式文件。解决办法是把编译产物一起带上。具体做法在本地完整编译一次确保参考文献正常显示然后把生成的.bbl文件一起打包上传。.bbl是已经处理好的文献列表目标环境只要读它就行不需要再跑一遍文献处理程序。.bib也一起传无害但不要指望它会被处理。不同文献方案的处理细节不一样。传统 BibTeX 路线.bbl是纯文本跟着主文件走就行。较新的 biblatex 路线.bbl的内容依赖后端程序兼容性要求更高如果非要在大版本之间来回切容易出现格式不匹配。我的建议是投稿用的这一版尽量用最保守的传统路线样式文件用平台内置的常见样式比如 plain、unsrt、ieeetr 这类不要依赖自己从某个会议模板里扒出来的.bst。自定义样式文件可以一起传但要确认文件名不带特殊字符。还有一个隐蔽的坑如果参考文献里有特殊字符比如某些语言的重音符号、数学符号而文件编码不一致编译会报错或者显示成乱码。统一用 UTF-8 保存所有文本文件这一条在多人协作时尤其重要因为不同编辑器的默认编码不一样。2.4 图片与外部资源的处理策略图片这一块我的原则是矢量优先、格式保守。矢量图PDF 格式在任何分辨率下都清晰而且体积通常更小。位图PNG、JPG用在照片或者软件截图这类场景。平台对格式有白名单具体包括哪几种以页面说明为准但 PDF、PNG、JPG 基本都在里面。较老的 EPS 格式通常也能用但会经历一次自动转换转换过程偶尔会出问题尤其是含透明通道或者特殊字体的 EPS。体积控制上我一般做三件事。第一把每张图的最终尺寸定下来不要在文档里用width1.0\textwidth把一张 4000 像素宽的图硬塞进单栏那样既没意义又浪费体积。第二导出 PDF 图的时候关掉不必要的元数据和高分辨率预览。第三附录里的补充大图单独评估实在放不下就考虑拆分或者放到外部数据仓库。字体的嵌入状态值得单独检查一下。有些作图工具导出的 PDF 里文字是以未嵌入的形式引用的字体在别人机器上打开会变成替代字体甚至乱码。检查方法很简单用任意一个能查看 PDF 属性的阅读器看字体列表里每一项是否标了已嵌入。没有嵌入的重新导出时选上嵌入字体选项。这类问题不会导致编译失败但会让你的稿子在读者那里显示得很难看属于典型的上传成功但质量打折。2.5 导出之后的自检清单在 Overleaf 里点下载源码压缩包之后我不会立刻传给平台而是先做一次本地复现。做法是把压缩包解到一个全新目录用命令行跑一遍完整编译看能不能在不依赖任何缓存的情况下从零产出 PDF。mkdir -p /tmp/rebuild cd /tmp/rebuild unzip ~/Downloads/project.zip rm -f *.aux *.log *.out *.synctex.gz *.toc pdflatex -interactionnonstopmode main.tex bibtex main pdflatex -interactionnonstopmode main.tex pdflatex -interactionnonstopmode main.tex三次编译加一次文献处理是标准套路目的是让交叉引用和文献编号都稳定下来。跑完之后检查两件事退出码里有没有 errorwarning 可以放过PDF 页数和图表编号是否和预期一致。自检清单我固化成了五条目录里没有*.aux、*.log、*.out、*.synctex.gz这类中间产物压缩包解开后主文件在根目录且能被自动识别所有\includegraphics引用的文件都真实存在大小写完全一致参考文献在全新目录下能正常显示没有问号压缩包总大小在平台限制之内且没有无关的备份文件混进去最后一条经常被忽略。很多人从 Overleaf 下载的包里会带一个隐藏目录或者旧版本的备份文件体积不大但会让文件数变多处理时间变长。花一分钟清理一遍比上传后等待处理再失败要划算得多。3. 元数据打磨决定曝光与归属的那几栏稿子编译通过只是入场券真正决定这篇预印本能不能被对的人看到、能不能被正确引用、将来会不会因为署名问题返工的是元数据那几栏。这部分填起来最快但填错的代价最高因为改元数据比改源码麻烦得多有些字段在公开之后基本就锁死了。我的做法是先在本地开一个纯文本文件把所有元数据字段逐条写好反复检查两遍再往页面里粘。这个习惯来自一次教训当时在网页表单里直接敲摘要粘贴的时候带进去一个不可见的特殊空格提交之后摘要里那句话显示得很奇怪只能走替换流程重新提交一遍。从那以后所有要粘进网页的长文本我都先在纯文本编辑器里过一遍。3.1 标题与摘要的写法为检索和复制而优化标题的写法有一个常被忽略的维度它会被大量复制粘贴到参考文献、邮件、幻灯片、聊天记录里。所以它要满足脱离上下文也能读懂。全大写的标题在有些检索系统里显示效果差而且不礼貌。带复杂数学公式的标题在纯文本环境下会变成一堆乱码别人想引用都不知道怎么打字。我的原则是标题里只保留必要的符号实在绕不开的公式用文字描述代替比如把基于 L2 范数的 XX写成基于二范数的 XX。摘要更麻烦一点因为它是纯文本字段不经过排版引擎。这意味着你在摘要里写的任何 TeX 命令都会被原样显示出来。我见过摘要里赫然出现\cite{...}和$O(n^2)$的情况显示出来非常难看。处理办法是把公式写成线性形式O(n^2)就写成 O(n²) 或者干脆写二次复杂度。不要用希腊字母的特殊 Unicode 符号有些系统的编码处理会把它们变成问号。首句尤其重要。检索结果、订阅推送、社交平台上的卡片往往只展示摘要的前一两句。所以第一句应该直接给出这篇工作做了什么、得到了什么结论而不是近年来随着某某领域的快速发展这类铺垫。这不是学术写作的规范问题是传播效果的问题。提示摘要里不要出现引用编号、不要出现图表编号、不要出现脚注标记。这些在纯文本环境里全部失效只会变成噪音。3.2 分类选择的判断逻辑主分类的选择我总结成一句话跟着读者走不跟着方法走。很多人的直觉是我用了某种技术手段所以应该投那个技术分类但分类的本质是决定这篇稿子出现在谁的订阅列表里。你用统计方法解决了一个生物信息学问题读者在生物信息学的列表里找你那就该选那个分类。选到方法分类里你的目标读者根本看不到。跨学科的工作还有一个交叉分类的选项。交叉分类的意思是主分类之外再挂一个次级分类让稿子同时出现在两个列表里。这个功能很好用但要注意两点一是交叉分类的数量有上限二是主分类只能有一个公告日期和引用格式都跟主分类走。判断标准是这篇工作的主要贡献属于哪个社区的讨论范围剩下的挂交叉。选错了怎么办在提交阶段是可以改的替换版本时元数据也能一并更新。但我建议尽量一次选对因为频繁改分类会让订阅者困惑也可能触发额外的审核。判断不准的时候去看同方向近半年公开的稿子都选了什么分类这是最靠谱的参考比看分类说明文字有效得多。还有一个实际约束前面提到的推荐确认机制。某些分类对首次在该分类提交的作者有额外要求需要已有提交记录的人做确认。这个要求只在特定分类生效具体范围以提交页面提示为准。如果你的主分类正好落在里面而你又没有确认人提交页面会直接卡住。我的处理方式是提前一两天试填一遍表单走到分类那一步看看有没有障碍别等到真要提交的当天才发现走不通。3.3 作者、单位与署名顺序的锁定策略署名这几栏我建议在动手整理源码之前就全部确认下来并且以书面形式发给所有合作者确认一遍。原因很现实预印本一旦公开署名顺序的修改就要走替换流程而且要解释原因非常麻烦。合作者之间关于顺序的讨论最好在稿子还没上传的时候就结束。具体填的时候有几个细节。作者姓名建议用能和 ORCID 之类标识对应得上的写法不要一会儿全名一会儿缩写同一批稿子保持一致的风格。单位信息写当前单位就行不要堆一串历史单位读者不需要知道你在哪儿流动过。通讯作者的邮箱要写一个长期有效的不要用即将失效的临时邮箱因为后续所有关于这篇稿子的通信都会发到那里。还有一个容易被忽略的点作者数量多的时候要注意表单里作者顺序的保存逻辑。有些表单是按添加顺序排的有些是手动拖拽排序的提交前一定在预览页面逐条核对一遍。我见过添加了十几位作者、结果预览发现顺序全乱、只能重填一遍的情况。3.4 许可证与版本策略的取舍许可证这一栏本质是在回答两个问题别人能怎么用这份稿子以及你自己保留了哪些权利。平台提供的选项通常包括几种知识共享协议的变体以及一个平台自己的默认授权条款。差异主要在是否允许商业使用是否要求署名是否要求衍生作品采用相同条款这几个维度上。怎么选我的判断链条是这样的先看这项工作后续要投的期刊有没有明确要求有要求就按期刊要求来这是硬约束。没有要求的话看你的诉求——希望尽可能广泛传播、包括被翻译和被用于教学选宽松的署名类条款担心被商业机构直接拿去用选带非商业限制的完全不想操心用平台默认的授权条款它保证平台可以长期存档和分发其余权利保留在你自己手上。版本策略上要建立一个概念版本号是递增的历史版本不会消失。你第一次提交形成 v1之后替换形成 v2、v3。读者点进去默认看到最新版但可以切回旧版查看差异。这个设计对纠错很友好但对手滑很残酷——如果你在 v1 里写错了关键结论v1 会永远留在那里只能靠 v2 的说明去弥补。所以提交前的校对值得多花时间。关于永久标识符稿子公开后平台会分配一个编号这个编号就是引用时用的那个。有些情况下还可以额外申请一个数据级的数字对象标识符方便和期刊版本做关联。这块按需处理就行不影响主流程。4. 上传与校验把报错按类拆开看上传这一步界面上就是选文件、点提交看起来简单。但背后的处理流程其实有好几步解压、识别主文件、按识别到的引擎编译、把产物打包成 PDF、生成预览。任何一步出问题你看到的都是处理失败加一段日志。学会读这段日志是从反复试错到一次通过的分水岭。我的经验是日志不要从头读也不要从尾读先搜关键字。搜索!开头的行那是 TeX 的报错标记搜索not found那是文件缺失搜索Emergency stop那是编译被强制中止。找到第一个错误之后只看它前后各二十行后面的错误大多是第一个错误的连锁反应一起改反而会乱。4.1 上传方式与自动处理流程上传通常有两种方式传一个包含全部源码和资源的压缩包或者逐个文件上传。压缩包是主流选择因为文件多的时候逐个传容易漏。打包时要注意一点压缩包的顶层目录结构会被保留所以不要在包里再套一层同名目录否则解压后主文件会藏在两级子目录里影响主文件识别。识别主文件的规则大致是扫描包内的.tex文件找到含文档类声明和文档环境起始标记的那个把它当作主文件。这个规则意味着两件事。第一你的主文件必须是一个完整可编译的文档不能是只含\input的壳子却没有文档环境。第二如果包里有多个满足条件的.tex文件比如你把旧版本也打进去了识别结果可能不是你想要的。清理无关文件这件事在这里体现出价值。处理流程跑完之后页面会给出编译状态和日志。状态正常的话还能直接预览生成的 PDF。我一般会在这个预览页面翻三页第一页看标题和作者有没有乱码中间随便找一页看图有没有丢最后一页看参考文献有没有正常渲染。这三页能覆盖八成的问题。4.2 编译日志的读法按错误类型分流把常见错误归一下类处理起来会快很多。下面这张表是我自己整理的基本覆盖了九成以上的失败场景。日志特征根本原因处理方式File xxx not found图片或子文件缺失、路径错、大小写不一致核对文件名与路径统一小写Undefined control sequence宏包未加载或版本不支持该命令补\usepackage或换兼容写法Missing $ inserted正文里出现了数学符号但没进数学环境定位行号补$或改用文本符号Too many }s花括号不配对常见于表格和宏定义从报错行往上找最近的未闭合括号Font ... not found使用了目标环境没有的字体换内置字体或改用 pdfLaTeX 路线Package ... Error某个宏包自身报错多为参数冲突看该宏包文档或降级/替换TeX capacity exceeded递归过深或单次处理内容过大拆分表格、简化宏、分批编译Emergency stop前面有更严重的错误导致中止往前找第一个!行表格里最值得展开的是Undefined control sequence。它有两种完全不同的成因一是你真的忘了加载宏包二是宏包加载了但版本里没有这个命令。区分方法是看这个命令属于哪个宏包去查该宏包的版本历史。如果是后者把命令换成老版本里存在的等价写法通常改动量很小。Missing $ inserted这类错误的迷惑性在于报错行号往往不是真正出问题的位置。TeX 的解析是贪婪的它可能读了几十行之后才发现前面少了一个符号。我的定位办法是从报错行往上找最近的、含有下划线或尖括号的文本那多半就是元凶。4.3 图片与字体的隐性失败有一类问题不会让编译失败但会让产物质量下降我把它们叫隐性失败。最典型的是图片被静默跳过——编译通过日志里只有一条 warning但 PDF 里那张图是空白框。原因是格式不在白名单里或者文件损坏。处理办法是打开产物 PDF 逐页扫一遍特别是那些用较老工具导出的图。字体的问题也属于这一类。前面提过嵌入检查这里再补一个细节某些作图工具导出的 PDF 里会带 Type 3 字体这类字体在某些阅读器里渲染模糊。能重新导出成 Type 1 或者 TrueType 就重导导不了就考虑把图转成高分辨率位图虽然牺牲了矢量特性但显示效果反而更可控。还有一个隐蔽的失败图片尺寸超出页面边界但编译不报错只在 PDF 里被裁掉一部分。检查方法是在文档里临时给每张图加一个边框肉眼看一遍有没有溢出确认没问题再把边框去掉。这个操作两分钟能做完比事后被读者指出要好。4.4 体积超限时的裁剪策略包体积超限的时候按下面的顺序动手从影响最小到影响最大先删中间产物.aux、.log、.out、.toc、.synctex.gz这一刀通常能省下不少再压位图把 PNG 改成有损压缩的 JPG或者降低实际像素尺寸到最终显示尺寸的两倍再优化矢量图用工具把 PDF 图里的冗余对象清理一遍去掉编辑历史和内嵌的预览图最后考虑拆分把附录里的大段内容、补充数据、扩展推导拆成独立文件或者放到外部数据仓库并在正文里给出链接我一般会在第一阶段就把前三件事做完因为它们不损失任何内容。真正需要权衡的是第四步拆分意味着读者要多跳一次体验会打折所以能不做就不做。5. 提交之后状态流转、修订与撤稿点下最终提交按钮之后事情并没有结束。接下来是一段等待期状态会经历几个阶段每个阶段都可能出现需要你处理的情况。理解这套流转逻辑能避免很多不必要的焦虑比如为什么我的稿子还没出现。5.1 状态阶段与公告节奏提交完成后的状态大致是这样几条线刚提交时是待处理处理完成进入审核队列审核通过后等待下一个公告批次公告之后正式公开并分配编号。整个过程中最不确定的是审核环节它可能几分钟就过也可能挂上一两天尤其在新账号首次提交或者内容触发额外检查的时候。公告是有固定节奏的通常按工作日批量发布每天有一个截止时刻超过这个时刻就顺延到下一批。具体时刻和节假日安排以页面公告为准。这条规则最大的实践意义是不要卡着截止时间提交。你的稿子在处理过程中可能需要你补充信息而补充信息的时间是算在流程里的。提前一天完成容错空间就出来了。如果稿子长时间停留在待处理状态先检查提交时填的邮箱有没有收到需要你操作的通知。有时候是平台在等你确认某个信息比如作者身份、分类归属、或者授权条款的选择而你漏看了邮件。这种情况我遇到过两次都是邮件进了推广分类被淹没了。5.2 替换版本的正确姿势发现错误需要更正走替换流程。替换的正确理解是在原来那条记录上追加一个新版本旧版本保留。替换时要重新上传源码包同时可以更新元数据。这里有两个要点。第一替换的源码包要是完整包不是增量。平台不会把新旧包做合并你传什么就是什么。第二替换说明要写清楚改了什么。这不是形式主义读者点到版本对比的时候会看这段说明。写修正了图 3 的标注错误比写更新有用得多。什么情况下不该用替换如果这是一份全新的工作、和原稿的核心内容已经不同那就应该单独提交一条新记录而不是把原记录改得面目全非。判断标准是读者看到新版会不会觉得这是另一篇论文。会就新发不会就替换。5.3 撤稿的语义与使用场景撤稿功能的存在是为了处理这份稿子不应该公开的情况比如发现了根本性错误、涉及未公开的专利或数据、或者作者之间出现了署名争议。它的效果是在记录上标记撤回状态但历史版本通常仍然可以访问编号也还在。也就是说它不是删除是作废标记。使用上要克制。频繁的撤回和替换会留下明显的操作痕迹对读者的信任有影响。我在准备阶段的策略是宁可慢一天也不要在公开之后手忙脚乱地补救。如果确实需要撤尽量在公告之前处理那时候影响面最小。6. 排查速查表与实操心得前面几节按流程顺序讲了各个环节最后一节我换一种组织方式把高频问题和应对办法压成一张表再补几条从实际踩坑里总结出来的经验。这些经验大部分不是文档里会写的但每一条都帮我省过时间。6.1 高频问题速查表现象最可能的原因优先尝试的处理上传后编译失败本地正常引擎或宏包版本不一致用最低兼容写法替换新命令引用全变问号缺编译好的文献列表文件本地编译后把 bbl 文件一起上传图片显示为空白框格式不支持或文件损坏转成 PDF 或 PNG 重新导出中文显示为方块字体不可用换内置字体或用 pdfLaTeX 加 CJK 方案标题或摘要出现乱码编码不一致或含特殊符号统一 UTF-8去掉 Unicode 数学符号处理长时间无进展在审核队列或被挂起查邮箱通知核对元数据完整性提交被拒提示分类不支持该分类需推荐确认换主分类或联系已有记录的作者确认包体积超限中间产物或大图未清理先删 aux/log再压位图页面溢出被裁切图宽超出文本宽度用相对宽度并检查单栏双栏差异版本号混乱重复替换或误发新记录明确修订与新工作的边界表格用起来快但有两个前提。一是先把日志里的第一条错误找出来别对着表面现象猜。二是改完一处就重新编译一次不要攒着几处一起改否则你无法判断是哪一处改动生效了。6.2 我在实际操作中总结的几条经验第一条也是最值钱的一条把投稿用的那一版工程单独冻结一份。我现在的做法是稿子定稿那天把整个 Overleaf 工程导出一个压缩包重命名为带日期的快照存到一个独立目录里。之后无论正文怎么改、图怎么换投稿就用这份快照。好处是你随时能回答我当时提交的到底是哪一版出了问题也能精确回滚。这个习惯救过我一次——三个月后期刊那边要求提供与预印本一致的版本我直接拿出了快照五分钟解决。第二条别在截止时间的最后一小时做任何改动。这个时段你能做的事情只有一件就是把已经验证过的包传上去。任何临时改动哪怕只是改一个错别字都会引入重新验证的成本而验证需要时间。我见过最惨的情况是为了改一个标点符号重新打包结果新包里漏了一张图最后一个小时全花在排查上还错过了当天的公告批次。第三条把文件命名当成接口设计来做。文件名不只是给你自己看的它是路径、是引用、是别人解压之后看到的第一印象。全小写、用连字符或下划线分隔、不带空格和中文、语义清晰这四条做到能规避掉一大半的路径类报错。我现在连本地草稿都按这个规范命名因为草稿迟早会变成投稿包。第四条摘要和标题写完用纯文本环境读一遍。把它们粘到一个不带任何格式的编辑器里看有没有奇怪的符号、有没有断行错位、有没有本该显示成上标的东西变成了一串字符。这个检查三十秒能做完但能避免公开之后看着别扭好几年。第五条合作者越多越要把元数据的确认前置。多人合作的稿子署名顺序、单位写法、通讯邮箱这三件事我建议在源码整理之前就定下来并且让每位合作者回复确认。听起来很官僚但比公开之后改署名要轻松得多。至于具体的确认流程怎么走各个团队有自己的习惯核心是别把这件事留到最后一天。6.3 最后说一点关于心态的事这套流程我第一次走的时候花了整整两天第二次半天现在基本能在两小时内完成从整理到提交。差别不在技术能力在于你有没有把每一步的失败模式记住。第一次的挫败感主要来自我明明在编辑器里看得到 PDF为什么它就是不过一旦理解了编辑器里能跑和陌生环境里能跑是两件事后面的问题就都变成可预期、可排查的具体问题了。还有一点值得提醒这套流程里最容易被跳过的恰恰是最省时间的部分——本地复现。很多人图快直接在网页上试失败了改一点再传反复几轮下来花的时间是本地完整跑一遍的好几倍。我现在的固定动作是打包之后先在一个干净目录里从零编译一次通过了再上传。这一步多花五分钟省下的是半小时的来回试错。至于那些平台规则层面的细节比如分类的推荐确认范围、体积上限的具体数值、公告截止的准确时刻这些会变每次提交前扫一眼提交页面的说明就行不用背下来。