把定期 newsletter 当成构建步骤
多数「发定期摘要」的建议都假设你需要一个调度器：cron、定时触发的 Lambda，或托管服务「每周二 9 点跑」。如果你的内容在 CMS 里全天更新、你只想在固定时间抓一版，那没问题。但若站点是静态的、内容只在部署时变化，调度器就是错误的抽象。
我把摘要当成 CI 里的一步，紧接在站点 build 和 deploy 之后。一个脚本——叫 send-recurring-newsletter 或随便符合你流水线的名字——每次 deploy 跑一次。从和站点相同的数据源读已发布的文章和项目列表，用共享模板生成摘要 HTML，从邮件服务商的 API 拉订阅列表并发送。没有 cron、没有 Lambda、没有「每 N 小时跑一次」的配置。触发条件是部署，不是时间。
什么时候这就够了
当内容以部署为界时这就够了。你通过合并和部署来发布。摘要是「这次部署里上了什么」。读者在有新内容时收到邮件，而不是时钟到点。节奏跟你的发布节奏走：每周部署就每周一封，每篇 post 都部署就每篇一封。脚本在「每次运行发一封」意义上是幂等的；你每次 deploy 跑一次，所以就每次 deploy 发一封。
你还需要一个提供发送、拉取/分段订阅者 API 的邮件服务商。Resend、SendGrid、Mailchimp 等都可以。脚本调 API，不需要服务商按时间替你跑代码。
什么时候才需要调度器
当应该触发摘要的是时间而不是部署时，才需要调度器。例如：当天累积活动的每日摘要、必须每周一发出不管你有没有发布的周报，或由其他系统（CMS、电商）更新的内容、你想在固定间隔抓一版。那时才真正需要 cron、Lambda + EventBridge 或托管 cron。关键问题是：触发条件是什么？若是「我部署时」，放 CI 就对了；若是「每周二」，就需要知道「今天星期几」的东西。
如何保持技术栈静态
在 CI 里跑摘要能让生产面保持静态。站点还是 CDN 上的文件。生产环境里跑的代码——如果有——只有注册和确认所需的最小 API。摘要脚本跑在和 build 同一个环境里：你的 CI runner。用同一个 repo、同一批内容文件、同一套环境变量（再加邮件服务商的 API key）。生产没有新组件，没有新服务要管、监控或付费，没有凌晨三点的冷启动。你 push 时脚本跑完，deploy 就结束。静态站、静态流水线，少一样按时间跑的东西。
我选这种取舍。摘要是「上次部署以来有什么新东西」，触发就是部署本身。当这和你工作方式一致时，用构建步骤比用调度器更简单，也能让技术栈保持你想要的静态程度。
