事情的起因是运营需要给用户推送各类活动邮件，产品便把实现邮件模板的需求交由我来完成，得，有需求咱实现便是了。一开始想的确实挺好，不就是个静态页面嘛，刷的一下就搞定了，然后邮件发送出去各种兼容性问题，所幸只是测试邮件，不然就炸锅了。果然事情没有想象中的简单，网上查了一下发现HTML邮件模板的编写还是有点学问在的（文末附有HTML邮件相关资源推荐）
编写前提
HTML邮件模板的编写，先排出以下前提条件
1. 邮件内容展示于第三方平台
2. 邮件的解析器比较老旧
以上两点前提是我们在编写HTML邮件时需要认识到的，根据这两点前提加网上的总结，我有以下注意点：
1. 采用table布局方式
根据前提条件2，在不知道邮件最终会在哪个第三方邮件平台上展示时，确保布局不能乱的情况下只能用最保守的布局方式，就是table布局。这个布局方法是早期的网页比较流行的方式，优点很明显，兼容性无敌
2. 注意兼容性，尽量有替代方案
还是前提条件2，尽量避免使用css3的语法，很大可能性会失效，那么要如何确定兼容性呢，文末有附上鉴别工具。在某些情况下，在与设计和产品反馈说兼容性不太好的情况下仍要采用当前设计（没错，这种情况也有很多），这时候就要尽量采用一些备用方案了。比如以下所示：
/* 失效情况下的补救方案 */
background: #00A9BA;
/* 渐变背景，有可能会失效 */
background: linear-gradient(90deg, #52D6CE 0%, #00A9BA 100%);
4. 行内样式优先
为什么说行内样式优先，是因为第三方邮件平台展示邮件内容的时候，有可能会去除邮件模板的head,style等标签，如果样式是统一存放与style标签内的，则模板也就乱了。所以，在编写邮件模板时，尽量使用行内样式实现。如果存在一些特殊的情况如需要处理响应式邮件时，就不得不用到style标签来做class的处理，这时候也得要有备用的兼容方案，比如移动端样式优先显示，通过媒体查询再显示PC端的内容。当然了，最好在设计前和设计师沟通一下（大雾
5. 不要存在定位
通过兼容性的查询可知，position属性基本不被主流邮件客户端支持，这东西最好不用就是了。具体的原因是什么没查到，这里可以猜测的是，如果开放position，那么有可能会将邮件客户端的内容给遮挡住，这也是很尴尬的
6. No JavaScript！
这个自不必说了，所有的邮件无法执行Javascript代码，为了安全性。所以如果产品有要求对邮件进行一些脚本操作，最好的办法就是跳转至自用的网站下再进行相应地操作。
7. 将元素放置于body中
将布局的内容及样式放置于body标签中，是为了防止第三方客户端删除头部、只保留body标签的情况出现。这里要注意的一点是，如果存在特殊情况下的style标签，那么留在body中存在的概率会大一些。
End
存手工编写是最靠谱也是最麻烦的方法，看实际情况而定，邮件的实现必要时也需要和产品以及设计沟通，切忌让设计天马行空的去搞，不然麻烦的还是前端（扯皮麻烦）。
以下是一些邮件资源，这里需要说明的是，这一类的框架优点是比较省事，不用写太多，那缺点也很明显，就是得学多一门几乎是新的语言
- MJML: https://mjml.io/
- emailframe http://emailframe.work/
- Foundation for Emails 2: https://foundation.zurb.com/e...
- responsive HTML email template: https://github.com/leemunroe/responsive-html-email-template
- campaignmonitor：https://www.campaignmonitor.com/a/
