企业官网建设流程全解析

1. 先把"投稿"当成一次构建发布来看

第一次把稿子推到 arXiv 上的时候，我在 Overleaf 里点了一下编译，绿色的对勾亮着，PDF 干干净净，心想这事十分钟就能搞定。结果上传完，平台回给我的编译日志里躺着七条错误，最扎眼的一条是找不到图片文件。后来才发现，是我在本地用了一个带空格的中文目录名，而平台解压之后路径全变了。从那次开始，我养成一个习惯：把 arXiv 投稿当成一次"构建发布"来做，而不是"上传一个 PDF"。这两件事的差别很大——前者要考虑目标环境的编译器版本、文件路径、依赖完整性；后者只关心我这台机器上能不能跑。

这篇内容讲的就是这条链路：怎么在一个在线协作编辑器（下文统一叫 Overleaf）里把工程整理成随时可以打包的形态，怎么把元数据填到不容易返工，怎么读懂上传之后那一大段编译日志，以及提交之后状态怎么流转。核心关键词是arXiv 投稿和Overleaf 准备，我把它们拆成两个独立但咬合的阶段：前半段解决"文件层面能不能编译通过"，后半段解决"元数据层面能不能被正确归档和检索"。

适合谁看？第一次投预印本、还没搞清楚分类和许可证区别的人；稿子已经在 Overleaf 里写完、但不知道怎么导出成可提交包的人；以及合作者众多、需要把工程交给别人复现的团队。如果你已经投过三五次，这篇里关于 bbl 文件、字体嵌入、公告截止时间的那几节，应该还能帮你省掉一两次返工。所有内容都基于我自己的操作经验和常见实践，具体规则以平台当时的页面提示为准，因为这类平台的功能和限制是会调整的。

1.1 预印本平台在这条链路上到底承担什么

很多人对预印本平台的定位是模糊的，觉得它是一个"免费的发表渠道"。这个理解会带来一连串误判。它更像一个带时间戳的公开存档：你上传一份稿件，平台给它一个永久标识、一个提交日期、一个版本号，然后把它放进公开可检索的索引里。它不做同行评审，不做学术判断，也不保证内容正确性。它能给你的东西是"我比你早"这个事实记录，以及一个可被引用的条目。

理解这一点，很多事情就顺了。比如为什么它可以接受格式不那么完美的稿件——因为它不是排版终端，最终排版是期刊的事。比如为什么它对源码结构那么挑剔——因为它的目标不是让你交一份漂亮的 PDF，而是让任何人下载源码后都能重新编译出同样的结果，这是长期存档的基本要求。再比如为什么提交之后还能替换版本——因为存档允许"同一份工作的演进"，v1 永远留在那里，v2 覆盖的是展示层。

我在实际操作中的体会是：把它当成"给未来的自己留一份可编译快照"来准备，通过率会高很多。你交付的不只是一篇论文，而是一套能在陌生环境里复现的构建材料。

1.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。

体积控制上，我一般做三件事。第一，把每张图的最终尺寸定下来，不要在文档里用width=1.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 -interaction=nonstopmode main.tex bibtex main pdflatex -interaction=nonstopmode main.tex pdflatex -interaction=nonstopmode main.tex

三次编译加一次文献处理是标准套路，目的是让交叉引用和文献编号都稳定下来。跑完之后检查两件事：退出码里有没有 error（warning 可以放过），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 编译日志的读法：按错误类型分流

把常见错误归一下类，处理起来会快很多。下面这张表是我自己整理的，基本覆盖了九成以上的失败场景。

表格里最值得展开的是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 高频问题速查表

表格用起来快，但有两个前提。一是先把日志里的第一条错误找出来，别对着表面现象猜。二是改完一处就重新编译一次，不要攒着几处一起改，否则你无法判断是哪一处改动生效了。

6.2 我在实际操作中总结的几条经验

第一条，也是最值钱的一条：把投稿用的那一版工程单独冻结一份。我现在的做法是，稿子定稿那天，把整个 Overleaf 工程导出一个压缩包，重命名为带日期的快照，存到一个独立目录里。之后无论正文怎么改、图怎么换，投稿就用这份快照。好处是你随时能回答"我当时提交的到底是哪一版"，出了问题也能精确回滚。这个习惯救过我一次——三个月后期刊那边要求提供与预印本一致的版本，我直接拿出了快照，五分钟解决。

第二条，别在截止时间的最后一小时做任何改动。这个时段你能做的事情只有一件，就是把已经验证过的包传上去。任何临时改动，哪怕只是改一个错别字，都会引入重新验证的成本，而验证需要时间。我见过最惨的情况是，为了改一个标点符号重新打包，结果新包里漏了一张图，最后一个小时全花在排查上，还错过了当天的公告批次。

第三条，把文件命名当成接口设计来做。文件名不只是给你自己看的，它是路径、是引用、是别人解压之后看到的第一印象。全小写、用连字符或下划线分隔、不带空格和中文、语义清晰，这四条做到，能规避掉一大半的路径类报错。我现在连本地草稿都按这个规范命名，因为草稿迟早会变成投稿包。

第四条，摘要和标题写完，用纯文本环境读一遍。把它们粘到一个不带任何格式的编辑器里，看有没有奇怪的符号、有没有断行错位、有没有本该显示成上标的东西变成了一串字符。这个检查三十秒能做完，但能避免公开之后看着别扭好几年。

第五条，合作者越多，越要把元数据的确认前置。多人合作的稿子，署名顺序、单位写法、通讯邮箱这三件事，我建议在源码整理之前就定下来，并且让每位合作者回复确认。听起来很官僚，但比公开之后改署名要轻松得多。至于具体的确认流程怎么走，各个团队有自己的习惯，核心是别把这件事留到最后一天。

6.3 最后说一点关于心态的事

这套流程我第一次走的时候花了整整两天，第二次半天，现在基本能在两小时内完成从整理到提交。差别不在技术能力，在于你有没有把每一步的失败模式记住。第一次的挫败感主要来自"我明明在编辑器里看得到 PDF，为什么它就是不过"，一旦理解了"编辑器里能跑"和"陌生环境里能跑"是两件事，后面的问题就都变成可预期、可排查的具体问题了。

还有一点值得提醒：这套流程里最容易被跳过的，恰恰是最省时间的部分——本地复现。很多人图快，直接在网页上试，失败了改一点再传，反复几轮下来，花的时间是本地完整跑一遍的好几倍。我现在的固定动作是，打包之后先在一个干净目录里从零编译一次，通过了再上传。这一步多花五分钟，省下的是半小时的来回试错。至于那些平台规则层面的细节，比如分类的推荐确认范围、体积上限的具体数值、公告截止的准确时刻，这些会变，每次提交前扫一眼提交页面的说明就行，不用背下来。