C# 使用 EWS 访问 Exchange 邮箱：从认证到避坑的完整指南-北京尧图网络

简介面向C#开发者的Exchange EWS接入指南以英文原版讲解微软EWS Managed API在邮件、日历、任务与联系人处理中的实际用法适合需要对接Exchange Server、构建企业邮件系统的开发人员。这份doc文档共1个文件压缩包仅147KB内容精炼涵盖程序集引用与命名空间配置、测试服务器自签名证书的验证回调处理、ExchangeService实例化与域凭据设置、服务URL自动发现及手动指定并给出FindItems获取邮件、EmailMessage发送邮件并保存副本等核心代码实例。文档展示从环境搭建到收发邮件的完整流程保留英文原文便于对照官方API文档理解细节。已有679人学习下载适合具备基础C#语法、希望快速上手EWS接入的开发者。1. 先用 C# 敲开微软 EWSExchange 邮箱访问到底在解决什么问题做过邮件集成的人大概都经历过这个瞬间老板丢来一句「把某个共享邮箱的附件定时抓下来」你第一反应是去翻 Outlook 的 COM 接口然后被 Release COM 对象、进程不退出、只能跑在 Windows 上有权限的交互桌面这些事折磨到怀疑人生。其实只要目标邮箱跑在微软 Exchange 上正路是走微软 EWS也就是 Exchange Web Services。用 C# 通过 EWS 访问 Exchange 邮箱本质上是和 Exchange 的 Web 服务接口对话读写邮件、日历、联系人、任务都走统一的 SOAP 协议不需要碰 Outlook 进程不需要装 OfficeLinux 上的 .NET 服务也能跑。这个方案适合三类人要做邮箱自动化集成的后端开发、要给业务系统加收发邮件能力的运维开发、以及被客户要求对接 Exchange 的乙方工程师。这篇笔记直接按「选型、最小闭环、认证、避坑、进阶」往下拆。2. 先选路线再动手EWS 托管 API 与原生 SOAP 怎么取舍2.1 两条路线托管 API 还是直接发 SOAP 请求EWS 对外暴露的接口本质是一组 SOAP 服务所有操作都是构造 XML 请求、解析 XML 响应。C# 开发者实际有两条路可走。第一条路是使用微软封装的 EWS 托管 API。它的 NuGet 包名是Microsoft.Exchange.WebServices核心程序集叫Microsoft.Exchange.WebServices.dll。托管 API 把 FindItems、Send、GetAttachment 这些操作封装成了强类型方法写起来像在操作一个内存里的对象集合不用关心 XML 长什么样。这是日常开发的首选。第二条路是直接用 HttpClient 构造 SOAP 请求。这条路虽然代码量大但胜在完全不依赖特定程序集抓到 WireShark 报文就能直接调试而且不受托管 API 自身的版本和平台限制。某些运行在 ARM 架构或者精简运行时上的服务反而走裸 SOAP 更顺。对比维度EWS 托管 API直接 SOAP 请求上手速度快几行代码就能跑通慢先要理解 SOAP 信封和 Action平台兼容.NET Framework / .NET Core 可用任何能发 HTTP 的语言都行调试难度需要开 Trace 看底层 XML报文本身就是要调试的东西细微控制能力部分高级参数被封装掉了请求头、分页、重定向全可控维护风险官方已停止大版本迭代接口随 Exchange 版本变化需自维护我的建议很直接本地 Exchange 和 Exchange Online 的日常读写无脑选托管 API如果你要做的功能是托管 API 里没有的或者客户端环境不允许引入额外 DLL再考虑裸 SOAP。项目标题既然是「基于 C# 的微软 EWS 访问 Exchange 邮箱」下文所有示例都按托管 API 写法来讲。2.2 环境准备目标 Exchange 版本与运行库动手写代码之前先确认邮箱跑在哪个 Exchange 版本上。EWS 从 Exchange 2007 SP1 开始提供但不同版本的行为差异很大。比如 Exchange 2010 及以后版本默认开启分页限制Exchange Online 则在逐步关闭基础认证这些都会直接影响你的代码能不能跑。.NET 侧建议直接上 .NET 6 或更高版本目标框架设为net6.0或net8.0。EWS 托管 API 虽然是老库但在 .NET Core / .NET 5 下可以正常引用只需要注意 TLS 配置。新建项目后加包dotnet add package Microsoft.Exchange.WebServices加包完成后在Program.cs或服务启动处显式声明 TLS 版本。这一步不做后面很容易遇到远程主机 SSL 连接失败ServicePointManager.SecurityProtocol SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;这段代码的逻辑是ServicePointManager是 .NET 里管理 HTTP 连接池的入口SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13表示同时启用 TLS 1.2 和 TLS 1.3。这里用按位或而不是直接赋值是为了不覆盖系统默认的其他协议。如果你的 .NET 运行时版本较老比如 .NET Framework 4.6.1默认最高只到 TLS 1.0必须手动加上这行否则 Exchange 服务器会直接拒绝握手。2.3 连接前必须确认的三件事我见过太多代码没跑通、最后发现是环境问题的案例。连 Exchange 之前先确认三件事能省下至少一天的排错时间。第一Autodiscover 域名记录是否可解析。Exchange 客户端默认会去猜autodiscover.你的邮箱域名.com这个地址。直接用 nslookup 验证nslookup autodiscover.contoso.com如果解析不出 IP后面代码里AutodiscoverUrl一定会超时。注意这个记录的 DNS 解析和 Exchange 服务器本身的解析是两码事很多企业内网 DNS 和外网 DNS 结果不一致代码跑在服务器上时要用服务器实测的结果来判断。第二证书链是否受信任。Exchange 的 HTTPS 证书如果是自签名或者由企业内网 CA 签发EWS 客户端默认会验证失败。托管 API 没有直接暴露跳过证书校验的口子常见做法是挂ServicePointManager.ServerCertificateValidationCallback来做自定义校验。但生产环境不建议全局跳过最好是把企业根证书装进受信任的根证书存储区。第三网络出口是否能直接访问 Exchange 终结点。这里的坑是EWS 请求走 HTTPS 443但 Autodiscover 阶段可能会发生 302 重定向从内网地址跳到外网地址。如果你的服务器防火墙只放行了内网 IP跳转后请求就会卡住直到超时。所以连接超时时间建议一开始就设短一点后面第 5 章会专门讲这个坑。3. 跑通最小闭环读收件箱、发邮件、翻页的 C# 骨架3.1 初始化 ExchangeService指定版本、凭据与终结点地址所有 EWS 操作都从ExchangeService这个核心对象开始。它相当于一个与 Exchange 服务器的会话句柄版本、凭据、访问地址都挂在它上面。using Microsoft.Exchange.WebServices.Data; var service new ExchangeService(ExchangeVersion.Exchange2013_SP1); service.Credentials new NetworkCredential(usercontoso.com, password); service.AutodiscoverUrl(usercontoso.com, RedirectionUrlValidationCallback); static bool RedirectionUrlValidationCallback(string url) { return url.StartsWith(https://); }逻辑说明ExchangeService的构造函数参数指定与服务器对话时使用的 EWS 版本它决定请求 XML 的 Schema 版本。Credentials是基础认证方式下的用户名和密码。AutodiscoverUrl会让客户端自动寻找邮箱所属的 Exchange 服务地址而回调函数RedirectionUrlValidationCallback在遇到跳转时被调用这里只放行 HTTPS 地址防止被重定向到明文 HTTP 或恶意地址。参数说明ExchangeVersion.Exchange2013_SP1不是说你服务器必须是 2013 SP1而是让客户端用这个版本的 Schema 来通信兼容性最广。如果你对接的是 Exchange Online也可以用它。AutodiscoverUrl的域名必须与凭据里的邮箱域名一致否则服务端会拒绝。如果你已经知道确切的服务地址比如管理员告诉你 EWS 地址是https://mail.contoso.com/EWS/Exchange.asmx可以直接跳过自动发现service.Url new Uri(https://mail.contoso.com/EWS/Exchange.asmx);显式指定Url的好处是省掉自动发现阶段的 DNS 解析和多次重定向排错时能少看很多日志。缺点是如果服务器迁移了代码里的地址要跟着改。我的做法是配置里放一个EWS_URL的配置项为空时走自动发现有值时直接用。3.2 用 FindItems 与 ItemView 拉取收件箱邮件读取收件箱是第一个必写的功能。这里有两个关键概念SearchFilter决定筛选条件ItemView决定一次取多少条、从第几条开始取。看代码var view new ItemView(50); view.PropertySet new PropertySet(BasePropertySet.IdOnly, ItemSchema.Subject, ItemSchema.DateTimeReceived); view.OrderBy.Add(ItemSchema.DateTimeReceived, SortDirection.Descending); var results service.FindItems(WellKnownFolderName.Inbox, view); foreach (var item in results.Items) { Console.WriteLine(${item.DateTimeReceived:yyyy-MM-dd HH:mm:ss} - {item.Subject}); } if (results.MoreAvailable) { view.Offset 50; }逻辑说明FindItems的第一个参数指定要搜索的文件夹WellKnownFolderName.Inbox是收件箱的预定义枚举。返回结果results.Items是当前页的邮件集合这里没有取邮件正文因为正文比较大默认不会随列表返回。results.MoreAvailable告诉你还有没有下一页。参数说明ItemView(50)的 50 是页面大小这个参数直接受 Exchange 服务器的节流策略影响超过服务器上限会被拒绝。我一般固定用 100 到 200别贪多。BasePropertySet.IdOnly表示只返回 ItemId后面需要的字段通过ItemSchema.Subject、ItemSchema.DateTimeReceived单独声明这样加载的属性越少请求越快。OrderBy按收件时间倒序保证第一页是最新的邮件。注意这里拿到的item是通用Item对象如果要访问附件需要把它转换成EmailMessage再调用Load方法。列表阶段只做摘要详细信息留给点击或批处理时再加载。3.3 按条件过滤邮件发件人、主题与时间范围实际需求很少是「拉全量收件箱」通常要带条件。比如抓取某个发件人的近 30 天邮件用SearchFilter组合即可var fromFilter new SearchFilter.IsEqualTo(EmailMessageSchema.From, bosscontoso.com); var dateFilter new SearchFilter.IsGreaterThanOrEqualTo(ItemSchema.DateTimeReceived, DateTime.UtcNow.AddDays(-30)); var searchFilter new SearchFilter.SearchFilterCollection(LogicalOperator.And, fromFilter, dateFilter); var view new ItemView(100); view.PropertySet new PropertySet(BasePropertySet.IdOnly, ItemSchema.Subject, ItemSchema.DateTimeReceived); var results service.FindItems(WellKnownFolderName.Inbox, searchFilter, view);逻辑说明SearchFilter是 EWS 托管 API 里的过滤表达式体系。IsEqualTo判断字段是否等于指定值IsGreaterThanOrEqualTo用于时间范围。多个条件用SearchFilterCollection组合LogicalOperator.And表示条件同时满足。参数说明发件人字段EmailMessageSchema.From比较特殊它内部是一个EmailAddress对象SearchFilter.IsEqualTo会自动按 SMTP 地址匹配。但要注意这里的匹配对地址的显示名和大小写比较宽松如果你发现过滤结果不准优先检查原文里存的发件人地址是不是有显示名前缀这在 Exchange 里是非常常见的现象。3.4 发邮件与已发送副本处理发送邮件的核心对象是EmailMessage创建后填充收件人、主题和正文然后调用发送方法var message new EmailMessage(service); message.ToRecipients.Add(someonecontoso.com); message.Subject 来自 EWS 的测试邮件; message.Body new MessageBody(这是测试正文验证 EWS 发送链路。); message.SendAndSaveCopy();逻辑说明New EmailMessage(service)创建一封绑定当前会话的空白邮件ToRecipients是收件人集合可以连续 Add 多个人。Body用MessageBody包装默认是 HTML 格式。SendAndSaveCopy表示发送并且在发件人邮箱的已发送邮件目录里保留一份拷贝。参数说明如果不想留底改用message.Send()而不是SendAndSaveCopy()。如果你的邮件需要附带附件在发送前调用message.Attachments.AddFileAttachment(D:\\report.pdf)附件会在发送时随邮件一起上传。这里有个容易忽略的点邮件发送是异步排队还是同步完成取决于服务器配置SendAndSaveCopy返回只代表请求被收到不代表对方已经收到邮件。4. 认证与权限从基础认证到 OAuth 2.0 和模拟访问4.1 基础认证什么时候能用什么时候会翻车标题里的场景最常见的问法就是「用户名密码怎么填」。先说结论如果你的邮箱跑在公司内网的本地 Exchange 上且没有开启 MFA基础认证是最快的方式代码就是第 3 章里的NetworkCredential写法。但如果目标邮箱在 Exchange Online也就是 Microsoft 365 的云端邮箱基础认证正在被微软分批关闭。一个典型翻车现场是昨天还能跑的定时任务今天突然报ErrorNone或者 401 Unauthorized查了半天发现是租户的基础认证已经被禁用或者用户开启了 MFA。密码认证在这种环境已经彻底失效必须换令牌。判断标准很简单公司有没有给你单独的安全策略页面用户登录网页版邮箱时是否要二次验证。只要有任何一条命中默认认为基础认证不可用直接走 OAuth 2.0。4.2 OAuth 2.0 客户端凭据流接入 EWSExchange Online 下的推荐认证方式是 OAuth 2.0 客户端凭据流官方要求在 Azure AD 注册应用并给应用添加EWS.AccessAsUser.All的 API 权限再用客户端 ID 和客户端机密去换访问令牌。拿到令牌后用OAuthCredentials挂到ExchangeService上。获取令牌的代码可以自己写用 HttpClient 请求令牌终结点即可。注意下面这段代码中的地址和参数按常见做法给出具体租户信息从配置读取var client new HttpClient(); var content new FormUrlEncodedContent(new Dictionarystring, string { [grant_type] client_credentials, [client_id] client-id, [client_secret] client-secret, [scope] https://outlook.office.com/.default }); var response await client.PostAsync(https://login.microsoftonline.com/tenant-id/oauth2/v2.0/token, content); var json await response.Content.ReadAsStringAsync(); var token System.Text.Json.JsonDocument.Parse(json).RootElement.GetProperty(access_token).GetString(); var service new ExchangeService(ExchangeVersion.Exchange2013_SP1); service.Credentials new OAuthCredentials(token); service.Url new Uri(https://outlook.office.com/EWS/Exchange.asmx);逻辑说明grant_typeclient_credentials表示这是应用以自己的身份访问不模拟任何用户。scope固定为https://outlook.office.com/.default意思是获取这个资源默认配置的权限集合。OAuthCredentials是托管 API 专门为令牌认证提供的凭据类型构造后赋给Credentials即可。参数说明tenant-id、client-id、client-secret都来自 Azure AD 的应用注册。如果注册应用时选了「受支持的账户类型」为仅此组织目录令牌终结点里的 tenant-id 就是你的目录 ID。这个认证方式不需要用户交互非常适合跑在服务器上的后台任务。但如果微软在租户里禁用了 EWS这一步还是会失败所以先确认组织的 EWS 访问级别没有被关闭这是合理的管理行为。4.3 共享邮箱与模拟访问以他人身份操作真实业务里经常需要读取某个同事的邮箱或共享邮箱。托管 API 提供了三种方式最常用的是模拟访问也就是以某个用户的身份操作他的邮箱数据。代码很简洁service.ImpersonatedUserId new ImpersonatedUserId(ConnectingIdType.SmtpAddress, bosscontoso.com);逻辑说明设置了ImpersonatedUserId之后后续所有 FindItems、Read 操作都作用在被模拟用户的邮箱上。ConnectingIdType.SmtpAddress表示用 SMTP 地址来标识被模拟的人也可以换成ConnectingIdType.Sid或ConnectingIdType.PrincipalName。参数说明模拟访问不是随便就能用的。服务账号必须在 Exchange 管理后台被授予ApplicationImpersonation角色。没有这个权限代码会直接抛出ErrorAccessDenied。注意模拟访问和共享邮箱授权是两套机制模拟访问是「以上级身份操作」共享邮箱是「以共享成员身份操作」。如果你只是要读写一个共享邮箱也可以直接把共享邮箱地址作为ImpersonatedUserId前提是服务账号对应了一个真实用户订阅且被授权这种情况在实际企业环境里比较少见。5. 避坑清单EWS 开发的五个常见翻车现场5.1 Autodiscover 超时但手动访问却正常现象AutodiscoverUrl调用后卡了很久最后抛TimeoutException。但你用浏览器打开https://autodiscover.contoso.com/autodiscover/autodiscover.xml明明能出结果。原因EWS 自动发现会尝试多个地址包括contoso.com/autodiscover和autodiscover.contoso.com。很多内网环境第一个地址解析慢或者超时重试客户端不等到超时完毕不会尝试下一个地址整体耗时被拉得很长。这类问题很玄学和客户端所在服务器的 DNS 解析顺序强相关。解决不要依赖自动发现直接绕过它。用管理员拿到的确切实地址service.Url new Uri(https://mail.contoso.com/EWS/Exchange.asmx)。实在要用自动发现就把AutodiscoverUrl包在带超时的任务里超时后 fallback 到显式地址。核心经验是EWS 的项目里尽量把终结点地址配置化留一个覆盖入口。5.2 收件箱明明有上万封程序只翻到 1000 封现象循环读分页Offset一直在加但读出来的邮件总数卡在 1000 封左右MoreAvailable还是 true继续翻就报错。原因Exchange 的节流策略MaxResultViewSize默认限制了单次搜索视图最多返回的条目数。不同版本上限不同常见配置是 1000。这意味着不管你Offset怎么加服务端只允许在这个范围内返回结果。解决不要试图一次把邮箱全量拉完。合理做法是缩小时间窗口比如按天、按周切分搜索或者用SeekToCondition做游标式翻页而不是用Offset物理跳页。物理跳页在数据量大时还有性能问题服务端每次都要跳过前面的条目。先确认需求是否真的需要全量遍历多数场景只要「最近 N 天」就够这种情况把时间过滤条件加上就绕开了 1000 封限制。5.3 邮件读出来了但正文和附件是空的现象FindItems返回了邮件列表Subject、DateTimeReceived都能打印但访问Body或Attachments时是 null 或者抛错。原因这是对 EWS 属性加载机制理解不到位。FindItems的ItemView返回的每个条目是一个轻量对象只包含你声明要的属性。正文和附件属于重属性和关联对象默认不会随着列表加载必须再发一次请求去 Load。解决拿到Item后如果需要详细内容先转成EmailMessage再调用Load加载扩展属性var email (EmailMessage)item; email.Load(new PropertySet(ItemSchema.Body, ItemSchema.Attachments));加载之后email.Body.Text才能拿到纯文本正文email.Attachments才有内容。这一点在 EWS 托管 API 里经常被误用社区里排名靠前的问题基本都归纳为同一句话列表和详情是两个请求别指望一次全给你。5.4 TLS 握手失败错误信息指向远程证书无效现象程序在一台老服务器上跑得好好的换到新服务器后突然报AuthenticationException错误信息提到The remote certificate is invalid according to the validation procedure或者握手失败。原因EWS 强制要求 TLS 1.2 以上。老服务器可能碰巧用的是 .NET Framework 4.7 以上版本默认启用了 TLS 1.2新服务器如果跑的是精简运行时或环境变量被改过默认协议栈可能只有 TLS 1.0直接被服务器拒绝。解决在程序启动最早的地方写死ServicePointManager.SecurityProtocol SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;如果这样还报证书校验错误再用ServerCertificateValidationCallback输出实际证书信息做对比。我见过最极端的案例是负载均衡器后面挂了一台过期证书的备份服务器请求被分发到那台机器上导致间歇性失败这种问题看代码是看不出来的只能抓包或者看服务端日志。5.5 发送邮件时报 ErrorNonExistentMailbox现象SendAndSaveCopy拋出ServiceResponseException内部错误码是ErrorNonExistentMailbox。你确认收件人地址没拼错。原因这个错误码并不完全等于「地址不存在」。它还包括收件人邮箱在另一个 Exchange 组织、收件人是一个组的显示名但在通讯簿里没有关联的 SMTP 地址、或者发件人被策略禁止向该域发送邮件。解决先用ResolveName验证一下收件人是否在通讯录里可解析var results service.ResolveName(someonecontoso.com, ResolveNameSearchLocation.ContactsThenDirectory, true);ResolveName返回匹配的通讯录条目如果能解析出Mailbox.Address一般不是地址问题继续往权限和传输规则方向排查。比较快的自查流程是用一个已知可用的收件人地址发一封测试邮件如果测试能发说明问题集中在收件人地址本身如果测试也发不了排查服务的发送权限和 Exchange 的接收连接器配置。6. 进阶把分页、限流和验证做成能扛生产的工程骨架6.1 分页游标与指数退避的实用写法生产环境的定时任务不能像 Demo 一样读一页就完事。我习惯把分页循环和重试逻辑包在一个方法里每次请求失败时按 2 的 n 次方秒退避重试最多重试 3 次var offset 0; const int pageSize 100; var retryCount 0; while (true) { try { var view new ItemView(pageSize, offset, OffsetBasePoint.Beginning); var results service.FindItems(WellKnownFolderName.Inbox, view); ProcessItems(results); retryCount 0; if (!results.MoreAvailable) break; offset pageSize; } catch (ServiceResponseException ex) { if (retryCount 3) throw; Thread.Sleep(TimeSpan.FromSeconds((int)Math.Pow(2, retryCount))); } }逻辑说明ItemView(pageSize, offset, OffsetBasePoint.Beginning)的三个参数分别是页大小、偏移量、偏移基准点。OffsetBasePoint.Beginning表示从查询结果的第一条开始偏移这是最常用的。ServiceResponseException是 EWS 操作失败时的主要异常类型里面包含ErrorCode和Message可以进一步按错误码细分重试策略。参数说明(int)Math.Pow(2, retryCount)实现了 2 秒、4 秒、8 秒的递增等待。对于节流错误这个策略通常能扛过去对于权限错误重试多少次都没用我建议把ErrorAccessDenied、ErrorNonExistentMailbox这类错误单独判断直接抛出人工介入。6.2 用请求日志验证 EWS 行为当 EWS 托管 API 把深层的 SOAP XML 藏起来之后排错时最有效的手段就是让它把请求日志吐出来。托管 API 内置了日志功能打开方法如下service.TraceEnabled true; service.TraceFlags TraceFlags.All; service.TraceListener new FileTraceListener(ews-trace.log);TraceFlags.All会把每个请求和响应的完整 XML 都写到日志文件里。看到 XML 中ResponseCode的值能直接定位到具体是被节流还是权限拒绝。日志文件在生产环境会涨得很快建议只在你复现问题时临时打开定位完就关掉。6.3 如果以后要迁向 Graph API现在就该留的接口Exchange Online 正在用 Microsoft Graph 逐步替代 EWS 的职能不是急转弯但趋势明显。给将来留后路的关键动作不要把 EWS 的类型散布到整个业务代码里而是包一层自己的邮件服务接口。接口方法名不要用FindItems、GetItem而是定义成ReadMailsAsync、SendMailAsync这类业务语义词。将来从 EWS 迁到 Graph 时只需要替换这一层的实现。常见业务EWS 托管 APIMicrosoft Graph读收件箱FindItems ItemViewGET /me/messages 或 /users/{id}/messages发邮件EmailMessage SendAndSaveCopyPOST /me/sendMail读共享邮箱ImpersonatedUserId/users/{共享邮箱}/messages限流控制ThrottlingPolicy 节流HTTP 429 Retry-After 头拿这个对照表去评估现有代码你会发现绝大多数操作在 Graph 里都有对应能力唯一复杂的是认证方式从 OAuth 客户端凭据流转到了委派权限加用户令牌令牌获取逻辑要做好兼容。最后说一个我自己的习惯接 Exchange 相关需求时第一步永远不是写代码而是先确认邮箱是在 Exchange Online 还是本地 Exchange、认证走基础认证还是 OAuth。这两个答案直接决定后面三五天的排错方向——认证选错前面所有代码都白写。希望帮到你。本文还有配套的精品资源点击获取

C# 使用 EWS 访问 Exchange 邮箱：从认证到避坑的完整指南

相关推荐

炼丹师的优雅内功三：TaoToken 视角下 kubeflow 如何承接机器学习任务

Codex多模型接入实战：网关路由与算力成本优化

MySQL内置函数实战指南：从字符串到窗口函数的用法与性能陷阱

更多资讯

Python机器学习从入门到精通：完整项目实战与踩坑指南

MASS框架解析：多智能体自监督递归自我改进的新路径

多模态语义路由实战：vLLM Decision 3.0 选型部署与踩坑记录

HMSC实战：从单物种到群落联合建模的生态统计路径

万能BIOS刷新工具UFU V8.93：原理、参数与救砖避坑指南

医院预约挂号小程序源码解析：号源并发扣减与订单状态回滚实战

今日更新

防关联浏览器哪个好？三款产品实测差异解析

2026钢铁行业AI转型系统选型对比：多基地排产、大宗原燃料采购与质量追溯，六家厂商能力差异在哪里

影刀RPA深度实战：大模型Fine-tuning定制RPA专用Prompt与指令生成

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？