通过谷歌服务安排邮寄活动（基础篇）
◍ 用谷歌服务给 MT5 用户群发邮件的接口思路
在 MT5 生态里做用户运营，邮件仍是最稳的触达方式之一。借助谷歌的邮件投递服务（如 Gmail SMTP 或 Google Workspace 邮件 API），可以把交易信号、账户异动、策略周报按订阅名单批量寄出，而不是手动在终端里逐个发。 实际落地时，MT5 本身不直接提供群发邮件 UI，需要借助外部脚本或 EA 调用网络组件。一个可行路径是用 MQL5 的 WebRequest 向自建中转服务发请求，再由该服务用谷歌 SMTP 凭据代发，这样能绕开 MT5 单发限制并保留投递日志。 公开案例数据显示，2019 年 8 月一篇相关技术帖在站内获得 2377 次查看、2 条讨论，说明这类「终端+谷歌邮件」的轻量集成确有刚需。外汇与贵金属交易本身高风险，任何自动化触达都应先获用户明示授权，避免合规雷区。
用 MQL 加 C# 打通邮件外发
想在 MT5 里定时给客户、订户或朋友群发邮件，顺带附上交易截图、日志或绩效报告，这种需求虽不天天有，但真到合规沟通或复盘同步时就显出价值了。原生 MQL 环境下直接做邮件编排几乎无解——标准库没有 SMTP 客户端，靠 MQL 单打独斗要么极难要么根本写不出来。 所以这一篇先不走纯 MQL 路线，而是用 MQL5 负责终端侧触发与数据采集，C# 侧承接 SMTP 发送与 Google 服务对接。这样代码量可控，逻辑也清楚，还能顺手碰一个挺有意思的终端—外部进程通信挑战。 本篇目标读者是已经会写 EA/指标、想进一步把自写库接进终端的中初级开发者；跟着做一遍，你能摸清如何用 C# 补上 MQL 缺失的邮件能力，并对 Google 相关服务调用建立直观认知。外汇与贵金属本身高风险，自动化外发若误触账户隐私也需自行评估合规边界。
「选 Google 通讯录当邮件列表底座」
先框定要做的活：维护一份可更新的联系人清单，支持向其中任意联系人发带附件的邮件，且单次或多次都行。清单里必然有坑——有人没填地址、填错地址，或挂了好几个地址；联系人会增删、会重复，也可能被临时踢出某次群发但留在总表里。 本地 HDD 库或 CSV 文件最省事但也最脆：换台机器就不一定找得到，还得额外软件编辑，可靠性不够。套个 Joomla 类 CMS 做网站数据库能解决异地访问和发信，但得装个不小的交互组件，攻击面也跟着放大，没有稳的基础设施撑不住。 直接复用 Google 现成服务反而最贴合：通讯录能跨设备管、能建组（比如建个叫“Forex”的组把人塞进去）、能发信，文档齐全。外汇/贵金属群发场景里联系人杂、地址乱是常态，用现成组做名单能少写一大堆存储代码，但注意 Google 字段不能自定义新增，好在内置字段够多，后面会演示怎么榨干它们。
◍ 给 MT5 之外的账号先开好两个接口
在动手写任何 MQL5 调用之前，先要在谷歌开发控制台里建一个项目，名字随便起，比如 "WorkWithPeople"。这个项目不是为了跑 EA，而是给后续跨平台取数据留通道。 项目建完，只需要启用两项服务：People API 和 Gmail API。前者能拉到账号下的联系人列表，官方已不推荐旧的 Contacts API，不用管它；后者顾名思义就是读写邮件用。 服务打开后，去生成访问密钥，以 json 文件形式下载到本地。文件里包含了应用调用谷歌资源所需的全部凭证，不必死记密钥串。举例来说，我本地存的文件名叫 "WorkwithPeople_gmail.json"，你换一个有意义的前缀也行。 到此为止，谷歌侧的动作就结束了——账号、联系人、项目、密钥文件四样齐活。下一步才是进 VS 2017 写对接代码，MT5 端还一行没碰。
VS2017 里把 Google 接口包装进类库
在 VS 2017 新建一个标准 Class Library（.NET Framework）工程，名字随意，我本地叫 WorkwithPeople，纯粹为了和后面要用的 Google 项目名对齐，不强制。 真正要紧的是用 NuGet 拉六个包：Google.Apis、Google.Apis.People.v1、Google.Apis.PeopleService.v1、Google.Apis.Gmail.v1、MimeKit。安装时 NuGet 提示连带装依赖项，直接同意，否则联系人读取和邮件收发的基础类型会缺引用。 装完之后工程里就具备了调用 Google 联系人服务与 Gmail 服务的最小集，下一步可以写实际交互代码，不需要再补别的运行时组件。
「联系人对象与地址校验的轻量封装」
做邮件触达前，先把谷歌联系人里用不上的字段砍掉。实际只需要两样东西：姓名和收件地址，所以用一个极简类承载就够了，初始化时传两个字符串，不在这里做合法性判断，检查留到发送前统一处理。
读取联系人时生成 OneContact 列表，后续邮件任务直接遍历这个轻量集合。若需刷新，先清掉旧元素再重新拉取筛选，避免脏数据堆积。
联系人列表里常混着空地址或写错的邮箱，发送前必须过一道校验。下面用扩展方法包了一层，比正则更省事，底层借用了框架自带的 EmailAddressAttribute。
校验逻辑只有一行：字符串非空且通过属性注解的 IsValid 才返回 true，否则 false。拿到这个布尔结果，主流程就能决定跳过还是继续投送。
别把地址校验想复杂
扩展方法挂在 string 上，调用时直接 email.IsValidEmail() 即可，无需自己维护正则，降低误判概率。
class="kw">namespace WorkWithPeople { internal sealed class OneContact { class="kw">public OneContact(class="type">class="kw">string n, class="type">class="kw">string e) { this.Name = n; this.Email = e; } class="kw">public class="type">class="kw">string Name { get; set; } class="kw">public class="type">class="kw">string Email { get; set; } } } class="kw">namespace WorkWithPeople { internal class="kw">static class ValidEmail { class="kw">public class="kw">static class="type">bool IsValidEmail(this class="type">class="kw">string source) => !class="type">class="kw">string.IsNullOrEmpty(source) && new System.ComponentModel.DataAnnotations.EmailAddressAttribute().IsValid(source); } }