同事发来一份带自动目录的项目说明文档，上传到网站后点开预览，目录里标着“第三章见第8页”，翻到正文却停在第11页。多数人的第一反应是文件损坏或上传出错，于是重新上传、换浏览器、换设备，折腾一圈问题依旧。其实这类现象大多不是文件本身坏了，而是文档的分页信息在网页端预览这个环节发生了变化。DOCX里的页码从来不是写死的数字，它由文档结构、转换过程和渲染环境共同决定，任何一环变动，目录页码就会跟着偏移。
先看文档自身的分节与页码设置。自动目录抓取的是正文中各级标题所在的实际页码，而页码又受分节符控制。一份文档如果中间插入了分节符，并且新一节设置为“起始页码为1”，那么目录在计算页码时就要按节分别累加。更常见的情况是封面和目录页使用了不同的页码格式，比如封面不显示页码、目录用罗马数字、正文从阿拉伯数字重新起算。此时若某一节的“起始页码”被误设为续前节或固定值，目录域刷新后就会整体错位。核对方法是打开文档，逐节查看页面设置里的页码起始方式，确认每一节的编号逻辑是否连贯，再右键更新整个目录域，观察页码是否与正文标题实际所在页一致。如果文档内部更新后就对不上，问题出在源文件，与网页端无关。
第二层看网页端的解析方式。DOCX本质是压缩包内的XML描述，网页预览通常要经过一次格式转换，把文档转成适合浏览器渲染的结构。不同转换工具对目录域的处理差异很大：有的会把目录当作普通文本，保留上传时缓存的页码数字；有的会丢弃域代码，只留下标题文字；还有的重新排版后按新的分页规则生成页码。也就是说，用户在本地看到的页码，和转换工具算出来的页码，可能来自两套完全不同的计算过程。核对时可以做一个简单对比：把同一份文档另存为PDF再预览，如果PDF页码正确而DOCX预览错误，基本可以判断是转换环节对分页信息的处理不一致，而不是文档内容有问题。
第三层容易被忽略，就是字体替换与行高变化对分页的影响。本地打开文档时用的是系统里安装的字体，网页端渲染时如果缺少同名字体，就会回退到替代字体。替代字体的字宽、行高、段间距哪怕只差一点点，累积到几十页文档里就足以让分页整体推移。测试方法很直接：在本地把文档中使用的字体临时替换为网页端常见的替代字体，重新分页并更新目录，看页码偏移是否复现。如果复现，说明问题来自字体环境差异，需要在转换端固定字体映射或嵌入字体，而不是反复检查上传流程。
把上面的排查整理成清单，可以按三个环节逐项确认。文档环节：检查分节符位置、各节页码起始设置、目录域是否为自动更新、页眉页脚是否占用额外空间。转换环节：确认转换工具是否保留分页信息、是否支持域代码重算、同一文档转PDF与转网页的结果是否一致。渲染环节：核对字体是否被替换、行高与段间距是否变化、预览容器是否强制了固定分页宽度。三项都过一遍，基本能定位偏移发生在哪一层。
处理建议上，上传前可以主动做一次自查：更新目录域后另存一份，关闭“打开时自动更新域”，避免预览时页码被二次计算；对页数较多的文档，在文件名或说明里标注总页数，方便用户对照。预览端则适合加一句提示，说明网页预览的分页可能与本地软件存在差异，引导用户以正文标题为准或下载原文件查看。it数运在网站维护中处理这类问题时，通常先区分是源文档结构问题还是转换渲染差异，再决定改文档还是调转换配置，避免让用户在上传环节反复试错。页码对不上不等于文件坏了，把核对顺序理清楚，问题往往比想象中简单。
