SharePoint 导出到 Excel：刷新究竟在哪一步执行

导出到 Excel 会依部署方式产生三种不同的产物，而出错只属于其中一种。下载的查询文件、静态 CSV 和会刷新的连接表并不是同一种结果，它们各自在不同阶段失败。判断手里是哪一种产物，决定下一步该交给网络团队、身份团队还是列表所有者。下面的机制沿着从浏览器到 Excel 自身请求的交接过程展开。

导出实际交接的是什么

在经典 SharePoint 列表中，导出到 Excel 会下载一个小文本文件，其正文是一个 URL；随后 Excel 读取该文件，并针对其背后的数据发出自己的请求。下载的文件只是一个指针，并不是列表本身。相比之下，CSV 导出包含的是行数据本身，与刷新没有任何连接。较新的连接表可以把查询直接嵌入工作簿，因此「下载」文件夹里根本不会出现任何文件。

所有连接形式都是单向的。刷新把列表中的当前行拉进工作簿，而编辑表不会回写任何内容。这种不对称对诊断很重要：一个用上周行数据打开的工作簿已经证明文件存在、连接也已保存，但它完全不能说明刷新今天是否可用。

所以第一个问题不是导行为什么失败，而是用户期待的是哪一种产物。答案把排查范围收窄到三条流程之一。

三条流程，三种不同的身份

浏览器中的下载使用浏览器会话，连带它自己的 Cookie、代理配置和登录状态。Excel 打开文件时使用的是 Office 自己的 HTTP 栈，它通常遵循每个用户的「Internet 选项」代理，而不是整台机器的 WinHTTP 设置，并且用用户所持有的 Office 身份进行认证。之后的刷新会复用已保存的连接，并可能直接从 Windows 凭据管理器中取用缓存的凭据，而不是弹出询问。

这三种上下文在同一台机器上可能互不一致，所以「浏览器能正常打开列表」与「Excel 刷新弹出登录提示」是可以并存的结论，并不矛盾。隧道会改变这三者的机器路由，但代理自动配置文件仍可能把 Office 的请求送到别处。

在改动任何一项之前，先记录每个阶段使用的身份。对浏览器做的修复无法解决 Excel 以另一个账户发出的请求。

改动任何东西之前，先读交接文件

下载的文件是纯文本，通常很短，所以先读它。它会写出 Excel 将要调用的主机和端点，而需要从用户机器上解析并完成认证的正是这个主机，不一定是浏览器地址栏里看到的地址。

Get-Content "$env:USERPROFILE\Downloads\query.iqy"
Resolve-DnsName team.example.net
netsh winhttp show proxy

把文件中的主机与用户以为的导出站点作对比。导出过程中的重定向、旧的网站集或被迁移的列表，都可能留下 一个指向已不再提供数据的名称的指针，由此产生的错误看起来像网络故障。如果名称能解析、端点也有响应，剩下的可能就只有认证和查询本身。

不要为了让它工作而把主机名换成 IP 地址。那会破坏证书名称校验，并把真正的问题藏在一个等到下次证书轮换就会失败的绕行方案之后。

把名称、登录和查询三类故障分开

四种结果几乎覆盖了所有报告，而每一种的责任方都不同。无法解析的名称属于 DNS。超时的连接属于路由或代理。登录提示或 401 属于身份。能到达但无法解析的响应，属于查询或列表现在暴露的那个端点。

最后一行才是人们经常误判的那一行。刷新能完成却返回错误的行，已经证明每个网络和身份层都是通的，剩下的问题就是查询携带的是哪个视图或筛选条件。把这张单子转给网络团队会白白浪费一天。

保留完整的错误文本和首次失败的时间。它决定了你处在表格的哪一行，也是列表所有者唯一能据以行动的凭据。

在同一列表上重新测试刷新

确定失败阶段之后，要重复那次失败的操作，而不是换一个更省事的操作。从预期的 Excel 环境、使用应有的账户和已批准的网络路径刷新同一个列表，并确认行数或某个已知被改动的值确实更新了。打开一个已保存的工作簿并不能证明连接可用。

不要轻易上大范围修补：清空全部已保存凭据、以提升权限运行 Office、关闭某项安全功能，都可能改变症状却没有修好出问题的阶段。如果认证就是失败的那一层，请让列表所有者确认账户与受支持的登录流程，而不是在客户端上猜。

只有当离线快照足以完成任务、且该导出在该环境中受支持时，才提供 CSV。改变输出格式会改变工作流程，也解释不了原本连通的操作为什么停下来。