简介：面向需要使用C#接入微软Exchange邮箱的开发者，这份英文技术文档围绕EWS Managed API展开，适合已具备C#与.NET基础、希望实现邮件处理、日历管理、联系人同步等企业邮箱自动化操作的中级读者。压缩包内仅含1个doc文件，约147KB，篇幅集中，便于快速通读和检索关键代码片段。资源已有682人学习，说明该主题在Exchange二次开发场景中具有稳定的参考需求。文档从程序集引用与命名空间引入讲起，覆盖测试服务器自签名证书的回调处理、ExchangeService实例创建、WebCredentials与NetworkCredential凭据设置、手动指定EWS地址及Autodiscover自动发现两种方式；并结合收件箱读取、EmailMessage发送、日历与任务联系人操作等示例，帮助读者理解EWS Managed API的调用链路与常见配置要点，可作为邮箱管理类C#应用的入门参考和代码速查材料。

1. 一份 DLL 顶掉半个邮件网关：Exchange EWS 到底能解决哪些活

上周有个做内部运维工具的朋友问我，Exchange EWS 这套接口现在还有没有必要接。我的判断很直接：只要目标环境是 Exchange 邮箱，又不想为了收发邮件、查忙闲、同步日历去扛一个第三方邮件库的兼容性包袱，C# 直连 EWS 仍然是最短的一条路。这份英文资料把 EWS Managed API 的入口讲得挺干净——一个Microsoft.Exchange.WebServices.dll加一份 IntelliSense XML，引进去就能开工，凭据、Autodiscover、邮件、日历、搜索、扩展属性都有可以照抄的片段。它适合已经会用 C#、手里有 Exchange 账号、需要在几天内做出邮件同步或会议预约功能的人；不适合想找现成 UI，或者指望靠图形化界面点两下就走通全流程的人。下面按我实际落地的顺序拆。

2. 把 Microsoft.Exchange.WebServices.dll 接进项目：从引用到第一个 ExchangeService 实例

这一章解决的是「能不能连上」的问题。很多人卡在这一步不是因为不会写代码，而是引用加错了、凭据传错了、地址选错了，报出来的错还都长得差不多。我一般会把连接部分的代码单独抽一个工厂方法，先在控制台里跑通，再往业务项目里搬。

2.1 两个文件的落位方式与引用检查点

资源里就两个文件：Microsoft.Exchange.WebServices.dll和Microsoft.Exchange.WebServices.xml。后者是 IntelliSense 注释文件，必须和 dll 放在同一个目录、且文件名前缀完全一致，Visual Studio 才会在敲service.的时候把方法说明弹出来。少了它代码照样能跑，但你会失去唯一的离线文档，写起来全靠猜。

我的习惯是项目根目录下建一个libs/EWS/，两个文件一起丢进去，然后在解决方案资源管理器里右键「引用 → 添加引用 → 浏览」，选中 dll。加完之后检查三件事：引用列表里出现Microsoft.Exchange.WebServices；该引用的「复制到本地」属性为 True，否则发布到服务器上会缺 dll；在对象浏览器里能展开Microsoft.Exchange.WebServices.Data命名空间。这三条都过了，再写using Microsoft.Exchange.WebServices.Data;才不会飘红。

这里有个容易被忽略的边界：这套 API 的原始发行形态是 .NET Framework 类库。把 dll 直接拖进 .NET Core 或更高版本的工程里，编译期可能过、运行期在序列化和 HTTP 层翻车的概率不低。我一般会先确认目标框架能拿到对应的发行版本，拿不到就老老实实让采集端跑在 .NET Framework 的控制台或 Windows 服务里，业务侧用消息队列对接，别硬上。

// 引用加好之后，这两行是整个项目的起点 using Microsoft.Exchange.WebServices.Data; using System.Net; // 把连接逻辑收在一个工厂里，后面所有业务代码都复用同一个实例 public static class EwsFactory { public static ExchangeService Create(string user, string password, string domain, string ewsUrl) { var service = new ExchangeService(); // 显式传凭据，不依赖当前登录身份 service.Credentials = new WebCredentials(user, password, domain); // 时区会影响 Appointment 时间的解释，必须设 service.TimeZone = TimeZoneInfo.FindSystemTimeZoneById("<你的时区ID>"); // 手工指定 EWS 端点 service.Url = new Uri(ewsUrl); return service; } }

这段代码里三个参数值得说清楚。WebCredentials的三个入参依次是用户名、密码、域，域一般先填 NetBIOS 短名，短名不通再换完整域名；TimeZone不是可选项，不设的时候服务端按 UTC 解释你传的DateTime，你会看到会议时间莫名其妙差几个小时；Url必须指向exchange.asmx这个具体端点，填到站点根目录会直接 404。

2.2 凭据三件套：WebCredentials、NetworkCredential 与域内免密

资料里提到一句很关键的话：当程序运行在已加入域并已登录的机器上时，可以不设置凭据。这句话本身没错，但它是个陷阱。我在本地调试时确实见过不设凭据也能跑通的情况，因为进程身份就是域账号，集成认证自动完成了握手。可一旦这段代码被搬到计划任务、IIS 应用程序池或者别的服务账号下，隐式身份就变了，报出来的还是那个看不出所以然的 401。

所以我的做法是永远显式设置凭据。WebCredentials本质上是对NetworkCredential的一层包装，两者可以互换，选哪个看团队习惯。区别在于WebCredentials在部分认证场景下会走 EWS 自己的凭据协商逻辑，NetworkCredential更贴近底层 HTTP 认证，遇到认证方式被策略限制的环境时，换一个试试往往能定位问题。

// 写法一：WebCredentials，三项式，最常见 service.Credentials = new WebCredentials("user01", "P@ssw0rd", "corp"); // 写法二：直接用 NetworkCredential，排查认证问题时用这个做对照 service.Credentials = new NetworkCredential("user01", "P@ssw0rd", "corp"); // 写法三：邮箱地址 + 密码（部分环境要求用户名就是完整 SMTP 地址） service.Credentials = new WebCredentials("user01@example.com", "P@ssw0rd");

三种写法对应三类环境，不要凭感觉选。判断依据很简单：先用写法一，401 就换写法三，还不行就抓一次 HTTP 层的认证头看服务端要求的是 Basic 还是 NTLM。另外提醒一句，密码不要硬编码在源码里，配置文件加密、环境变量或者密钥管理服务都比写在const string里强，这条血泪经验是用一次代码审计换来的。

2.3 服务地址：手写 Url 还是交给 Autodiscover

资料里给了两条路：手工service.Url = new Uri(...)，或者service.AutodiscoverUrl(...)。它推荐后者，理由站得住：Autodiscover 会为用户挑最近的邮箱服务器端点，而且管理员新增客户端访问服务器之后 EWS 地址可能变，硬编码的地址迟早失效。

但 Autodiscover 不是银弹。它要发一串 DNS 查询和 HTTP 请求，首次解析慢，网络策略严格的环境里还可能被拦。我的折中方案是：首次用 Autodiscover 解析，拿到service.Url之后缓存起来（数据库、配置文件都行），后续请求直接用缓存的地址；同时设一个刷新周期，或者捕获到连接异常时再重新解析一次。资料里也明确说了可以安全缓存 Autodiscover 返回的 URL，这一点和我的实践一致。

// 路线 A：Autodiscover 解析，入参是邮箱地址而不是登录名 service.AutodiscoverUrl("user01@example.com", ValidateRedirectionUrlCallback); // 解析完把结果落盘，下次直接读 string cachedUrl = service.Url.AbsoluteUri; File.WriteAllText("ews.endpoint.cache", cachedUrl); // 路线 B：读缓存，跳过解析 service.Url = new Uri(File.ReadAllText("ews.endpoint.cache"));

两条路只能选一条，资料里专门强调了「不要同时设置 Url 又调用 AutodiscoverUrl」。同时用的时候，后设置的会覆盖先设置的，行为取决于调用顺序，排查起来非常费劲。另外AutodiscoverUrl的参数是邮箱地址，不是域账号用户名，传错了会解析到一个完全不相干的端点。

2.4 测试服务器的自签名证书：回调怎么写才不算自废武功

测试环境部署的 Exchange 用的是自签名证书，.NET Framework 默认不信任，第一次连上去必然抛The remote certificate is invalid according to the validation procedure。资料给的解法是挂ServicePointManager.ServerCertificateValidationCallback，还特意加了一句注释：总是返回 true 不是好做法。这句话是整份资料里最该被记住的一句。

原因是ServicePointManager是进程级的静态入口，你在这里挂的回调会影响当前进程内所有 HTTPS 请求，不只是 EWS。一旦无条件return true，这个进程里所有 TLS 校验全部失效，包括你后面可能加的下载、上报、鉴权请求。我的写法是主机白名单加证书指纹双保险，只对测试服务器放行，其他一律交给默认逻辑。

using System.Net.Security; using System.Security.Cryptography.X509Certificates; // 白名单：只放行测试环境的这一台主机 private static readonly string[] TrustedHosts = { "test-mail.example.com" }; private const string TrustedThumbprint = "<测试服务器证书指纹>"; public static void EnableTestServerCertificate() { ServicePointManager.ServerCertificateValidationCallback = (object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors errors) => { // 1) 证书完全正常，直接通过 if (errors == SslPolicyErrors.None) return true; // 2) 只容忍「根证书不受信任」这一种错误 // 域名不匹配、证书过期一律拒绝，不做任何妥协 if (errors != SslPolicyErrors.RemoteCertificateChainErrors) return false; // 3) 从 sender 反查请求主机，不在白名单直接拒 var request = sender as HttpWebRequest; if (request == null) return false; if (Array.IndexOf(TrustedHosts, request.Host) < 0) return false; // 4) 再比对证书指纹，防止同名主机被顶替 return string.Equals(certificate.GetCertHashString(), TrustedThumbprint, StringComparison.OrdinalIgnoreCase); }; }

四个参数的含义要弄清楚再用：sender是发起请求的对象，在 .NET Framework 下是HttpWebRequest，EWS Managed API 走的正是这条链路；certificate是服务端出示的证书，可以取指纹、颁发者、有效期；chain是证书链，自签名证书在这里通常是断裂的；errors是SslPolicyErrors的位标志组合，可能同时包含多个错误，所以要用按位判断而不是相等判断。

2.5 Autodiscover 重定向校验：回调里必须挡住的两类地址

资料里花了不小篇幅讲 Autodiscover 的重定向风险：解析过程可能包含基于 DNS 的重定向，默认情况下AutodiscoverUrl不会跟随重定向，检测到需要重定向就抛异常；要允许跟随，必须实现 URL 校验回调，并且明确写了「永远不要无条件返回 true」以及「只允许重定向到 SSL 端点」。

这段是全文安全意识最强的地方，也是实际项目里最容易被删掉的地方。我见过有人为了让解析通过，直接在回调里return true，等于把端点解析的决定权交给了任意一台能返回重定向响应的服务器。我的回调固定只做三件事：判空、判协议必须是 https、判主机后缀在自家域内。

private static bool ValidateRedirectionUrlCallback(string url) { // 回调内部不要向外抛异常，异常会被吞掉，排查时什么线索都没有 try { if (string.IsNullOrWhiteSpace(url)) return false; // 只允许 https，http 一律拒绝 if (!url.StartsWith("https://", StringComparison.OrdinalIgnoreCase)) return false; Uri uri; if (!Uri.TryCreate(url, UriKind.Absolute, out uri)) return false; // 只允许重定向到自家域下的主机 return uri.Host.EndsWith(".example.com", StringComparison.OrdinalIgnoreCase); } catch { // 校验过程本身出错，按拒绝处理 return false; } }

调用时用带回调的重载：service.AutodiscoverUrl("user01@example.com", ValidateRedirectionUrlCallback)。两个细节：回调里绝不能抛异常，因为调用方通常不做细粒度捕获，异常会被包装成一个语义模糊的解析失败；主机后缀判断要注意.example.com前面的点，漏了点会匹配到notexample.com这种伪造域名。

3. 邮件、回复与循环会议：EmailMessage 和 Appointment 的八个高频动作

连上之后就是业务动作。资料把 EWS Managed API 的对象模型画成了一棵类树，Item下面是EmailMessage、Appointment、Contact、Task、PostItem，Folder是另一棵树。这个分层不是学术摆设，它直接决定了你拿到的对象能不能强转、绑定的时候该用哪个类型。

3.1 ItemId 与 Bind：先绑定再取详情的两种写法

Exchange 里每个条目都有唯一标识，ItemId对应条目、FolderId对应文件夹。拿到 ID 之后要取详情，走的是Bind。这里有个分支：明确知道是邮件就用EmailMessage.Bind，不确定类型就用Item.Bind拿基类再按运行时类型分发。

// 已知类型：直接绑到 EmailMessage EmailMessage message = EmailMessage.Bind(service, new ItemId(uniqueId)); Console.WriteLine(message.Sender.Name); // 未知类型：先绑基类，再分发 Item item = Item.Bind(service, new ItemId(uniqueId)); if (item is EmailMessage mail) { Console.WriteLine(mail.Sender.Name); } else if (item is Appointment appointment) { Console.WriteLine(appointment.Start); } else { // 其他类型，按需处理 }

Bind的第二个参数是ItemId对象而不是字符串，别直接传字符串。第三种重载可以传PropertySet，决定这次绑定要拉回哪些属性——不传的时候默认只拉第一类属性，Sender、Body这些常用字段都在里面，但自定义扩展属性不在，这个区别在第 4 章还会撞上。

3.2 发信：Send 与 SendAndSaveCopy 的差别

发信是三条语句的事：建对象、填属性、调发送。资料里用的是SendAndSaveCopy，这个方法会把邮件放进「已发送」文件夹；对应的Send只发不存副本。选哪个不是风格问题，是合规问题——有些团队要求所有外发邮件必须留档，那就只能用SendAndSaveCopy。

EmailMessage message = new EmailMessage(service); message.Subject = "每日巡检结果"; message.Body = new MessageBody(BodyType.HTML, "<p>附件为今日巡检汇总，请查收。</p>"); message.ToRecipients.Add("ops01@example.com"); message.CcRecipients.Add("ops02@example.com"); // 发送并在「已发送」保留副本 message.SendAndSaveCopy();

MessageBody的第一个参数是正文类型，BodyType.HTML和BodyType.Text二选一，选 HTML 的时候正文里不要塞未转义的尖括号。收件人集合的Add接受字符串，内部会隐式转成EmailAddress，需要显示名的时候构造EmailAddress对象再添加。发给多个收件人不要循环调用发送，往ToRecipients里加多个地址即可，一次Send搞定。

3.3 回复与转发：ResponseMessage 比 Reply 多出来的控制权

一键回复用Reply(body, replyAll)，两个参数：回复正文、是否全部回复。够用，但stopper在这里：它不能改收件人、不能加抄送、不能调整正文前缀的格式。需要这些控制就走CreateReply拿到ResponseMessage，改完再发。

// 简便写法：直接全部回复 messageToReplyTo.Reply(new MessageBody(BodyType.Text, "已收到，稍后处理。"), true); // 需要加抄送、改正文前缀时走 ResponseMessage ResponseMessage response = messageToReplyTo.CreateReply(true); response.BodyPrefix = new MessageBody(BodyType.Text, "已收到，补充抄送相关同事。"); response.CcRecipients.Add("ops02@example.com"); response.SendAndSaveCopy();

转发对应Forward和CreateForward，套路完全一样。这里有个细节值得记：BodyPrefix是加在原文上方的，不是替换原文；想让回复里带上原始邮件全文，靠的是服务端自动拼接，不需要你手动把原正文塞进去。另外CreateReply生成的响应对象不调用发送方法就什么都不会发生，它只是草稿。

3.4 循环会议：WeeklyPattern 的三个必填参数

循环会议是资料里参数最密的一段。Recurrence.WeeklyPattern的三个参数分别是模式起点、周间隔、以及一个可变参数的星期集合。起点决定从哪天开始算周期，间隔决定是每周还是每两周，星期集合决定一周里哪几天发生。

Appointment appointment = new Appointment(service); appointment.Subject = "周例会"; appointment.Body = new MessageBody(BodyType.Text, "每周二、周四固定同步进度。"); appointment.Start = new DateTime(2024, 5, 7, 10, 0, 0); appointment.End = appointment.Start.AddHours(1); appointment.Location = "3 号会议室"; // 每 2 周，周二 + 周四 appointment.Recurrence = new Recurrence.WeeklyPattern( appointment.Start, // 模式起点，决定周期从哪天开始算 2, // 间隔：每 2 周一次 DayOfWeek.Tuesday, DayOfWeek.Thursday); appointment.Save();

三个参数里最容易错的是起点。起点不是「第一次会议时间」这么简单，它同时决定了间隔的锚点，起点填错会导致整个循环序列整体偏移一周。Start和End必须落在同一个逻辑日内，跨天的会议在循环展开时行为不直观。

把已有会议升级成带参会人的正式会议，是给RequiredAttendees加人再Update：

appointment.RequiredAttendees.Add("member01@example.com"); // AutoResolve：遇到并发修改时自动合并，不抛冲突 appointment.Update(ConflictResolutionMode.AutoResolve);

ConflictResolutionMode有三个常见取值：NeverOverwrite遇到冲突直接抛异常，AutoResolve尝试合并，AlwaysOverwrite强制覆盖。生产代码里我一般用AutoResolve，被覆盖的如果是别人刚改的会议时间，会议室就白订了。

3.5 文件夹与删除：DeleteMode 选错就找不回来

文件夹绑定和条目绑定同构，已知 ID 用FolderId，已知是标准文件夹用WellKnownFolderName。标准文件夹枚举覆盖收件箱、日历、任务、联系人、已发送等，用它比记 ID 稳。

// 绑定到收件箱，不需要知道 ID Folder inbox = Folder.Bind(service, WellKnownFolderName.Inbox); // 新建一个子文件夹，挂在收件箱下 Folder folder = new Folder(service); folder.DisplayName = "巡检归档"; folder.Save(WellKnownFolderName.Inbox);

删除的三种模式必须分清：MoveToDeletedItems是软删除，进「已删除」还能恢复；SoftDelete对普通用户不可见但仍在邮箱里，只有走恢复流程才能找回来；HardDelete直接抹掉，没有后悔药。我吃过一次亏——清理测试数据时顺手用了HardDelete，把一批本该归档的邮件真删了，后面靠备份才补回来。

// 生产环境默认用这个 message.Delete(DeleteMode.MoveToDeletedItems); // 仅用于确认可丢弃的数据 // message.Delete(DeleteMode.HardDelete);

个人通讯组也在这一层，DistributionList建完之后Save即可，成员用DistributionListMember构造，两个参数是显示名和邮箱地址。资料里这段写得很简短，但实际项目里通讯组往往是批量导入的入口，建议先小批量验证再去重。

4. 搜索分页与扩展属性：把收件箱几千封邮件捞干净的写法

只要邮箱里超过几百封邮件，就不能再靠FindItems一次拉完。这一章的几个参数决定了两件事：你的程序会不会被服务端限流，以及你会不会漏数据。

4.1 ItemView 的三个参数：页大小、排序、属性集

ItemView是查询的载体，构造参数是页大小，另外两个关键属性是排序和属性集。页大小不要贪大，服务端对单次返回条数有上限（常见是 1000），设得比上限还大没有意义，反而更容易触发超时。

ItemView view = new ItemView(10); // 按收件时间倒序，最新的在前 view.OrderBy.Add(ItemSchema.DateTimeReceived, SortDirection.Descending); // 只拉这三个属性，别用默认的全量 view.PropertySet = new PropertySet( BasePropertySet.IdOnly, ItemSchema.Subject, ItemSchema.DateTimeReceived);

属性集这一行是性能关键。BasePropertySet.IdOnly表示只带 ID 和极少数基础字段，加上Subject和DateTimeReceived之后，返回的每个条目只有这三个字段有值。不裁剪的话，正文、附件元数据、收件人列表全都会被拉回来，几千封邮件能把内存和带宽一起吃掉。代价是没在属性集里的字段会是 null，第 5 章有一条坑专门讲这个。

4.2 分页遍历：Offset 递增与 MoreAvailable 的配合

分页的写法是do-while，靠MoreAvailable判断还有没有下一页，靠view.Offset往前推进。资料给的骨架是对的，但两个位置不能写错：Offset的累加放在循环体末尾，MoreAvailable的判断放在循环条件里。

ItemView view = new ItemView(50); FindItemsResults<Item> page; do { page = service.FindItems(WellKnownFolderName.Inbox, view); foreach (Item item in page.Items) { // 处理当前页，注意这里只有属性集里的字段有值 Console.WriteLine(item.Subject); } // 推进偏移量，数量必须和 ItemView 的页大小一致 view.Offset += 50; } while (page.MoreAvailable);

Offset的增量和ItemView的页大小必须严格一致，一个写 50 一个写 100，中间就会漏掉一半数据，而且不会报错，只是结果看上去「少了一些」。另一个边界：分页期间如果有新邮件到达或者有邮件被删除，偏移量分页会出现重复或漏读，这是偏移量分页的固有特性。对完整性要求高的场景，我会改用时间窗过滤（按DateTimeReceived分段查询），比偏移量稳。

4.3 SearchFilterCollection：OR 组合与 ContainsSubstring 的边界

搜索过滤器支持逻辑组合，SearchFilterCollection的第一个参数是逻辑运算符，后面是若干子过滤器。资料里的例子是「主题包含 EWS 或包含 API」，用LogicalOperator.Or组合两个ContainsSubstring。

SearchFilterCollection filter = new SearchFilterCollection( LogicalOperator.Or, new SearchFilter.ContainsSubstring(ItemSchema.Subject, "EWS"), new SearchFilter.ContainsSubstring(ItemSchema.Subject, "API")); FindItemsResults<Item> results = service.FindItems( WellKnownFolderName.Inbox, filter, view); Console.WriteLine("命中总数：" + results.TotalCount);

TotalCount和Items.Count不是一回事：Items只是当前页，TotalCount是符合条件的总数，做分页 UI 的时候要用后者。ContainsSubstring走的是子串匹配，对中文分词的支撑很有限，搜「巡检」能命中「巡检结果」，但搜「结果巡检」不会命中；复杂的检索需求建议把数据同步到本地库再做全文检索，别指望 EWS 的过滤器。

4.4 扩展属性：GUID 属性集与 MapiPropertyType 的写入读出

Exchange 允许在条目上挂自定义属性，EWS 里叫扩展属性。定义三要素：属性集 GUID、属性名、MAPI 类型。资料特意提醒 GUID 要自己生成新的，不能照抄示例，否则会和别的应用的属性撞车。

// 属性集 GUID：整个应用只定义一次，全局复用 Guid propertySetId = new Guid("{11111111-2222-3333-4444-555555555555}"); ExtendedPropertyDefinition ticketDef = new ExtendedPropertyDefinition( propertySetId, "TicketNo", MapiPropertyType.String); // 写入 EmailMessage message = new EmailMessage(service); message.Subject = "带工单号的邮件"; message.SetExtendedProperty(ticketDef, "WO-20240507-001"); message.Save(); // 读出：绑定时必须把扩展属性定义带进 PropertySet PropertySet ps = new PropertySet(BasePropertySet.FirstClassProperties, ticketDef); EmailMessage loaded = EmailMessage.Bind(service, new ItemId(uniqueId), ps); foreach (ExtendedProperty ep in loaded.ExtendedProperties) { Console.WriteLine(ep.PropertyDefinition.Name + " = " + ep.Value); }

读这一段最容易踩的坑：绑定时不传PropertySet，ExtendedProperties集合就是空的，你会以为属性没写进去。MapiPropertyType要和值类型对得上，用String定义却塞整数，写的时候不报错、读的时候类型转换失败。属性集 GUID 一旦上线就不要再改，改了等于所有历史数据都读不到。

4.5 Availability 服务：忙闲查询与会议时间建议

查别人日历有没有空，不需要有对方邮箱的读权限，走 Availability 服务就行。这是 EWS 里被低估的一个能力，做会议预约、值班排班的时候特别省事。

List<AttendeeInfo> attendees = new List<AttendeeInfo> { new AttendeeInfo("member01@example.com"), new AttendeeInfo("member02@example.com") }; GetUserAvailabilityResults results = service.GetUserAvailability( attendees, new TimeWindow(DateTime.Now, DateTime.Now.AddDays(1)), AvailabilityData.FreeBusyAndSuggestions); foreach (AttendeeAvailability availability in results.AttendeesAvailability) { // 先看 ErrorCode，没错误再读 CalendarEvents if (availability.ErrorCode != ServiceError.NoError) continue; foreach (CalendarEvent ev in availability.CalendarEvents) { Console.WriteLine(ev.StartTime + " - " + ev.EndTime); } }

三个参数：参会人列表、时间窗、要返回的数据类型。FreeBusyAndSuggestions表示既返回忙闲时段也返回推荐会议时间，只要忙闲就传FreeBusy。时间窗别开太大，一次查一个月和一次查一天，服务端压力差着一个量级。遍历结果一定要先判ErrorCode，某个参会人解析失败的时候对应的CalendarEvents是空的，不判就会静默少人。

5. 避坑与排查：五条血泪记录，每条都对应一个 ErrorCode

下面五条都是我在真实项目里撞过的，按「现象 → 原因 → 解决」写，看到相似的报错可以直接对号入座。

5.1 连接与凭据类

第一条：本地能跑，部署到服务器就 401。

现象：开发机上调通的代码，发布到应用服务器后所有请求返回 401 Unauthorized，日志里没有任何服务端错误码。

原因：本地是域账号登录，走的是集成认证，凭据从来没显式传过；到了服务器上，进程身份变成了应用程序池账号或者本地系统账号，隐式身份根本不在域内，服务端直接拒绝。

解决：构造函数里强制显式传WebCredentials，把账号密码域三件套从配置文件读进来。同时确认服务账号没有开启交互式二次验证——这类环境下密码认证会被直接拒绝，需要换成应用专用凭据或者更现代的认证方式，具体走哪条要看服务端策略，别自己猜。

第二条：Autodiscover 解析超时或者解析到内网地址。

现象：AutodiscoverUrl调用卡住十几秒然后抛异常，或者解析成功但后续请求连不上。

原因：Autodiscover 依赖 DNS 和目录里的服务连接点记录，办公网和服务器网段看到的结果可能不一样；解析出来的端点在内网，从外网访问自然不通。

解决：把解析结果缓存下来，只在首次或者连接失败时重新解析；如果确定端点固定，直接手工设Url并跳过 Autodiscover。排查阶段先用nslookup看解析结果，再看返回的 URL 主机名能不能 ping 通，两步就能定位是解析问题还是网络问题。

5.2 数据与查询类

第三条：查出来的邮件 Sender 是 null。

现象：FindItems拿到的条目，Subject有值，Sender、ToRecipients全是 null。

原因：ItemView.PropertySet里设了BasePropertySet.IdOnly之后，只有显式列出的属性会被加载，Sender不在其中。

解决：往PropertySet里补ItemSchema.Sender和ItemSchema.ToRecipients；或者分两步走，列表页只取 ID 和主题，用户点开详情时再EmailMessage.Bind单独拉完整属性。前者适合数据量小的场景，后者在几千封邮件的时候更划算。判断依据就是你到底需不需要在列表页展示这些字段。

第四条：分页遍历结果少了三分之一。

现象：do-while分页跑完，统计出来的条数明显少于邮箱实际数量，程序不报任何错。

原因：view.Offset的增量和ItemView的页大小不一致，比如页大小设了 50、偏移量每次加 100

本文还有配套的精品资源，点击获取